latest sshd upgrade
Hi, I noticed on the latest openssh MFC, the previous behaviour of sshd checking both authorized_keys2 and authorized_keys is no longer the default. # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys vs # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys #AuthorizedKeysFile .ssh/authorized_keys in sshd_config. Is there a reason why this was done ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
troubles with buildworld/sendmail/sasl/clang
Hi all, since some days i try to make buildworld, but have some errors in sendmail. The make conf is not changed since years (in this case) . Adding NO_WERROR= in src.conf helps, but i think it is not the optimal solution? # SASL (cyrus-sasl v2) sendmail build flags... SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+=-L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL SENDMAIL_MC = /etc/mail/xyz.mc WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient ==src.conf=== CC=clang CXX=clang++ CPP=clang-cpp # This setting to build world without -Werror: # NO_WERROR= # This setting to build kernel without -Werror: # WERROR= =buildworld=== /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] getsasldata, NULL, XS_AUTH); ^~~ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: passing argument to parameter here extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); ^ /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from macro '__P' #define __P(protos) protos /* full-blown ANSI C */ ^ 3 errors generated. *** [usersmtp.o] Error code 1 1 error *** [all] Error code 2 1 error *** [usr.sbin.all__D] Error code 2 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error regards beat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A few problems
On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: Hello there. I've got a couple of things I don't get or can't handle. [...] re0@pci0:4:0:0: class=0x02 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xf8ff, size 65536, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) speed 2.5(2.5) cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 description: ToISP options=8218bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4,WOL_MAGIC,LINKSTATE ether 00:21:85:1c:24:fa media: Ethernet autoselect (100baseTX full-duplex) status: active [...] One is that re0 doesn't neogatiate direct link with a connected PC (using non-crossover UTP), but sk0 does that easy. It seems to me that according to RTL8111 chip specification there shouldn't be any problem, probably it's a driver problem? What is your link parter for re0? I don't remember whether the PHY hardware really supports automatic MDI crossover detection. Even if the PHY hardware does not support it, the link partner would be able to do that. And could you show me the output of dmesg(re(4) and rgephy(4) only) and devinfo -rv | grep rgephy? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: latest sshd upgrade
Mike Tancsa m...@sentex.net writes: I noticed on the latest openssh MFC, the previous behaviour of sshd checking both authorized_keys2 and authorized_keys is no longer the default. [...] Is there a reason why this was done ? authorized_keys2 has been deprecated for ages... but I shouldn't have merged that change. I'll revert it. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
System doesn't resume with active vbox VM
My system doesn't resume with an active VirtualBox VM, in this case Windows XP/32. I didn't test any other systems. The system comes back to the console screen, but doesn't get back into X. After a couple of seconds (no dump occurs) I get the BIOS screen and the system reboots with unclean file systems. # uname -a FreeBSD mobileKamikaze.norad 9.1-STABLE FreeBSD 9.1-STABLE #3 r247136: Fri Feb 22 00:52:22 CET 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 amd64 Hardware virtualization is turned on, the additions are installed in the VM. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A few problems
2013/3/18 YongHyeon PYUN pyu...@gmail.com: On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: Hello there. I've got a couple of things I don't get or can't handle. [...] re0@pci0:4:0:0: class=0x02 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xf8ff, size 65536, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) speed 2.5(2.5) cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 description: ToISP options=8218bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4,WOL_MAGIC,LINKSTATE ether 00:21:85:1c:24:fa media: Ethernet autoselect (100baseTX full-duplex) status: active [...] One is that re0 doesn't neogatiate direct link with a connected PC (using non-crossover UTP), but sk0 does that easy. It seems to me that according to RTL8111 chip specification there shouldn't be any problem, probably it's a driver problem? What is your link parter for re0? I don't remember whether the PHY hardware really supports automatic MDI crossover detection. Even if the PHY hardware does not support it, the link partner would be able to do that. And could you show me the output of dmesg(re(4) and rgephy(4) only) and devinfo -rv | grep rgephy? Here's info: re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf,0xf8ff-0xf8ff irq 17 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:21:85:1c:24:fa devinfo -rv | grep rgephy rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1 This link connected to Realtek 8111E under Win7. I'll repeat that when it's connected to sk0, everything works. Of course when I'm switching links, I change IPs and other configuration in rc.conf and reboots system. For example I'll provide info for sk0 (Dlink DGE-530T): skc0: D-Link DGE-530T Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebec000-0xfebe irq 17 at device 1.0 on pci5 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:19:5b:86:3b:53 miibus1: MII bus on sk0 e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus1 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x5 at phyno=0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: troubles with buildworld/sendmail/sasl/clang
On Mon, Mar 18, 2013 at 1:03 PM, Beat Siegenthaler beat.siegentha...@beatsnet.com wrote: Hi all, since some days i try to make buildworld, but have some errors in sendmail. The make conf is not changed since years (in this case) . Adding NO_WERROR= in src.conf helps, but i think it is not the optimal solution? # SASL (cyrus-sasl v2) sendmail build flags... SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+=-L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL SENDMAIL_MC = /etc/mail/xyz.mc WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient ==src.conf=== CC=clang CXX=clang++ CPP=clang-cpp # This setting to build world without -Werror: # NO_WERROR= # This setting to build kernel without -Werror: # WERROR= =buildworld=== /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] getsasldata, NULL, XS_AUTH); ^~~ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: passing argument to parameter here extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); ^ /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from macro '__P' #define __P(protos) protos /* full-blown ANSI C */ ^ 3 errors generated. *** [usersmtp.o] Error code 1 1 error *** [all] Error code 2 1 error *** [usr.sbin.all__D] Error code 2 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error regards beat I can not help with the error but I really have to make this question: Does FreeBSD really have to support pre-ANSI C compilers in 2013? -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: troubles with buildworld/sendmail/sasl/clang
On Mar 18, 2013, at 12:03, Beat Siegenthaler beat.siegentha...@beatsnet.com wrote: since some days i try to make buildworld, but have some errors in sendmail. The make conf is not changed since years (in this case) . Adding NO_WERROR= in src.conf helps, but i think it is not the optimal solution? # SASL (cyrus-sasl v2) sendmail build flags... SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+=-L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL ... /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] getsasldata, NULL, XS_AUTH); ^~~ We used to build sendmail with NO_WERROR.clang= to disable -Werror specifically for clang, because there were some warnings that could not be suppressed otherwise. But since r246880 we reverted that workaround, so this may be why you are now seeing these -Werror messages. In any case, if you are pulling port headers into your buildworld, the effect is not always predictable, as ports are largely independent from base. So if you need a customized build of sendmail, would it not be better to use the mail/sendmail port instead? There you can easily enable all bells and whistles that are not enabled by default in base. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: troubles with buildworld/sendmail/sasl/clang
On 18.03.13 18:19, Dimitry Andric wrote: We used to build sendmail with NO_WERROR.clang= to disable -Werror specifically for clang, because there were some warnings that could not be suppressed otherwise. So if you need a customized build of sendmail, would it not be better to use the mail/sendmail port instead? There you can easily enable all bells and whistles that are not enabled by default in base. Ok, good point... force of habit. Since years. Will use Port... regards, Beat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A few problems
Hi-- On Mar 16, 2013, at 2:08 AM, Michael BlackHeart wrote: Hello there. I've got a couple of things I don't get or can't handle. I'm running: FreeBSD diablo.miekoff.local 9.1-STABLE FreeBSD 9.1-STABLE #0 r248347: Sat Mar 16 03:20:58 MSK 2013 root@diablo.miekoff.local:/usr/obj/usr/src/sys/DIABLO64 amd64 1st of all, on dmesg there's something strange. It says: real memory = 6442450944 (6144 MB) avail memory = 4092743680 (3903 MB) So real memory is about 6Gb, but localy installed only 4Gb. [ ... ] You've got an Intel P45 northbridge controller which supports dual-channel mode, but that only works for DIMMs of the same size. You might be able to get 6GB if you place the DIMMs in slots 1 and 2 instead of 1 3 or 2 4. Otherwise, try getting another 4GB DIMM and using 4GB + 4GB instead. Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: troubles with buildworld/sendmail/sasl/clang
Hi,
On Mon, 18 Mar 2013 18:19:18 +0100
Dimitry Andric d...@freebsd.org said:
dim On Mar 18, 2013, at 12:03, Beat Siegenthaler
beat.siegentha...@beatsnet.com wrote:
since some days i try to make buildworld, but have some errors in
sendmail.
The make conf is not changed since years (in this case) . Adding
NO_WERROR= in src.conf helps, but i think it is not the optimal solution?
# SASL (cyrus-sasl v2) sendmail build flags...
SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2
SENDMAIL_LDFLAGS+=-L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL
dim ...
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8:
error: incompatible pointer types passing 'void ()' to parameter of type
'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)'
[-Werror,-Wincompatible-pointer-types]
getsasldata, NULL, XS_AUTH);
^~~
dim We used to build sendmail with NO_WERROR.clang= to disable -Werror
dim specifically for clang, because there were some warnings that could not
dim be suppressed otherwise. But since r246880 we reverted that workaround,
dim so this may be why you are now seeing these -Werror messages.
dim In any case, if you are pulling port headers into your buildworld, the
dim effect is not always predictable, as ports are largely independent from
dim base. So if you need a customized build of sendmail, would it not be
dim better to use the mail/sendmail port instead? There you can easily
dim enable all bells and whistles that are not enabled by default in base.
No, it seems to me that this error is not depending on sasl header. I
suspect clang still has some problem in handling __P.
Sincerely,
--
Hajimu UMEMOTO
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A few problems
2013/3/18 Chuck Swiger cswi...@mac.com: Hi-- On Mar 18, 2013, at 11:16 AM, Jeremy Chadwick wrote: You've got an Intel P45 northbridge controller which supports dual-channel mode, but that only works for DIMMs of the same size. You might be able to get 6GB if you place the DIMMs in slots 1 and 2 instead of 1 3 or 2 4. Otherwise, try getting another 4GB DIMM and using 4GB + 4GB instead. Off-list: Except that Michael said, re: his dmidecode output: As you see it says that in DIMM4 there's 4Gb module, but it's 2Gb actualy. It's a Kit of 2x2Gb. BIOS says that there's only 4Gb but FreeBSD see 6Gb. I'll try later to switch modules into DIMM1 DIMM3 but I'm not expecting any difference. So let's recap: - DIMMs are operating in single-channel mode (vs. dual-channel) Are they? (I didn't see info one way or the other, but perhaps off-list communication confirmed that.) - DIMM2 claims to be 2GB - DIMM4 claims to be 4GB - Intel P45 supports up to 16GB RAM (4GB maximum per DIMM) - OS is amd64 If he did have 4GB+2GB installed, since he's using amd64, ideally he would be seeing FreeBSD report avail memory = (around 6GB), which isn't the case. So something isn't making sense here. Right. If one DIMM really is 4GB, then putting them into slots 1 2 should make a difference; or just install only one at a time to double-check. Possibly the SMBIOS/DMI data claims to have a 4GB DIMM, yet in actuality chip-wise only has 2GB on it. In which case, the SMBIOS/DMI data is wrong, or the DIMM manufacturer is shady. I would not be surprised if the user had two DIMMs bought at different times (even if they're the same model), or that one is just manufactured wrong/badly. Maybe. If you put different sized DIMMs into slots paired up for dual-channel mode, IIRC that era of Intel chipsets would work in dual-channel mode using the smaller memory size. That resembles the current situation rather closely-- ie, 6GB installed but only 4GB available. But I suppose it could be a DIMM which claims to be the wrong size in DMI info Regards, -- -Chuck I checked out. It's a kit of 2x2Gb as I said before. And I moved them to 1 and 3 slots and nothing changed. currently do not have any DDR2 modules to make some more tests. Here's proof: http://www.miekoff.ru/wp-content/uploads/P1020858.jpg And for the record, I used this memory on two other motherboards, one was running WinXP and another FreeBSD 8.3 and later 9.1. And all of them reported about 4Gb installed. Just like BIOS does. So it seems to me like some weird thing. On the one side it could be a FreeBSD's DMI mis-interpretating. On the other side as far as I know Corssair do not produce something, but just tunes and overclocks memory chips. And because of the radiators I can't visually compare chips one of them easily could be a 4Gb module locked to 2Gb or something like that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: troubles with buildworld/sendmail/sasl/clang
On Mar 18, 2013, at 19:54, Hajimu UMEMOTO u...@freebsd.org wrote:
...
dim In any case, if you are pulling port headers into your buildworld, the
dim effect is not always predictable, as ports are largely independent from
dim base. So if you need a customized build of sendmail, would it not be
dim better to use the mail/sendmail port instead? There you can easily
dim enable all bells and whistles that are not enabled by default in base.
No, it seems to me that this error is not depending on sasl header. I
suspect clang still has some problem in handling __P.
It is not because of the __P macro specifically, but because of the way
the function parameters are promoted for KR functions. The
getsasldata() function is first declared as:
static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE *));
Directly after that, it is defined as a KR function:
static void
getsasldata(line, firstline, m, mci, e)
char *line;
bool firstline;
MAILER *m;
register MCI *mci;
ENVELOPE *e;
{
...
About 1000 lines below that definition, the address of getsasldata gets
passed to reply(), which is declared as:
extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void
(*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int));
so it accepts a function pointer parameter which matches the initial
prototype of getsasldata(), but *not* the actual definition!
Now, clang normally warns about the 'firstline' parameter being promoted
from bool to int, as is required for KR functions:
contrib/sendmail/src/usersmtp.c:618:7: warning: promoted type 'int' of KR
function parameter is not compatible with the parameter type 'bool' declared in
a previous prototype [-Wknr-promoted-parameter]
bool firstline;
^
contrib/sendmail/src/usersmtp.c:612:42: note: previous declaration is here
static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE *));
^
but since we suppress that warning using -Wno-knr-promoted-parameter, we
do not see it during build world. However, this still means the
function type is to be considered incompatible.
This changes only when the definition of getsasldata() is moved further
down in the file, specifically below all the places where it is passed
as a function pointer to reply(). In that case, the compiler does not
know yet the function is defined as KR, and considers it to be
compatible.
One way to avoid this whole mess would be to stop pretending sendmail is
C99 code, and define the 'bool' type as an int. That would solve all
the KR promotion problems in one fell swoop. And it requires just a
minor hack in contrib/sendmail/include/sm/gen.h.
Or, alternatively, fix all the function definitions to be actual C99
function definitions, but that would be a lot more work. :-)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Functional KDE desktop
On 18/03/2013, at 3:02, Eric S Pulley pul...@dabus.com wrote: I have it working fine here. I originally was using it on 9.0 then I upgraded everything but that didn't work well for the KDE 4.8-4.9 update in ports. Too many ports were split and moved around so I ended up removing all ports and remaking them all. One big gotcha is make sure you force a reconfigure on everything. My small nightmare was kdepim,kdepim-runtime and kdepimlibs there are now two deferment types of PIM you can built the old 4.8 style and the new. Make sure you are consistent as these packages are deps for many others. For a while I was still picking up settings for the old style and it was breaking all over the place. Ugh I see. Any idea what these options are called? If you want I can send you a list of all the stuff I have installed off list and you can see if you're somehow missing important bits... I ended up nuking all of KDE/Qt and will try again. I also have had troubles with Python updates and a few things. I really like ports when installing but they are terrible when upgrading :( -- 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 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A few problems
On Mon, Mar 18, 2013 at 05:19:11PM +0400, Michael BlackHeart wrote: 2013/3/18 YongHyeon PYUN pyu...@gmail.com: On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: Hello there. I've got a couple of things I don't get or can't handle. [...] re0@pci0:4:0:0: class=0x02 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xf8ff, size 65536, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) speed 2.5(2.5) cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled cap 03[d0] = VPD ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 0100684ce000 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 description: ToISP options=8218bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4,WOL_MAGIC,LINKSTATE ether 00:21:85:1c:24:fa media: Ethernet autoselect (100baseTX full-duplex) status: active [...] One is that re0 doesn't neogatiate direct link with a connected PC (using non-crossover UTP), but sk0 does that easy. It seems to me that according to RTL8111 chip specification there shouldn't be any problem, probably it's a driver problem? What is your link parter for re0? I don't remember whether the PHY hardware really supports automatic MDI crossover detection. Even if the PHY hardware does not support it, the link partner would be able to do that. And could you show me the output of dmesg(re(4) and rgephy(4) only) and devinfo -rv | grep rgephy? Here's info: re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf,0xf8ff-0xf8ff irq 17 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:21:85:1c:24:fa devinfo -rv | grep rgephy rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1 This link connected to Realtek 8111E under Win7. I'll repeat that when it's connected to sk0, everything works. Of e1000phy(4) supports automatic crossover detection/correction. I thought newer RealTek 8211 PHYs also support the feature but it seems it's not enabled by default. Could you try attached patch and let me know how it goes? course when I'm switching links, I change IPs and other configuration in rc.conf and reboots system. For example I'll provide info for sk0 (Dlink DGE-530T): skc0: D-Link DGE-530T Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebec000-0xfebe irq 17 at device 1.0 on pci5 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:19:5b:86:3b:53 miibus1: MII bus on sk0 e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus1 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x5 at phyno=0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A few problems
On Tue, Mar 19, 2013 at 01:56:29PM +0900, YongHyeon PYUN wrote:
On Mon, Mar 18, 2013 at 05:19:11PM +0400, Michael BlackHeart wrote:
2013/3/18 YongHyeon PYUN pyu...@gmail.com:
On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote:
Hello there. I've got a couple of things I don't get or can't handle.
[...]
re0@pci0:4:0:0: class=0x02 card=0x512c1462 chip=0x816810ec rev=0x02
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller'
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled
bar [18] = type Memory, range 64, base 0xfeaff000, size 4096,
enabled
bar [20] = type Prefetchable Memory, range 64, base 0xf8ff,
size 65536, enabled
cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit
cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link
x1(x1)
speed 2.5(2.5)
cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled
cap 03[d0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected
ecap 0002[140] = VC 1 max VC0
ecap 0003[160] = Serial 1 0100684ce000
re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
description: ToISP
options=8218bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4,WOL_MAGIC,LINKSTATE
ether 00:21:85:1c:24:fa
media: Ethernet autoselect (100baseTX full-duplex)
status: active
[...]
One is that re0 doesn't neogatiate direct link with a connected PC
(using non-crossover UTP), but sk0 does that easy. It seems to me that
according to RTL8111 chip specification there shouldn't be any
problem, probably it's a driver problem?
What is your link parter for re0? I don't remember whether the PHY
hardware really supports automatic MDI crossover detection. Even if
the PHY hardware does not support it, the link partner would be
able to do that.
And could you show me the output of dmesg(re(4) and rgephy(4) only)
and devinfo -rv | grep rgephy?
Here's info:
re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port
0xd800-0xd8ff mem 0xfeaff000-0xfeaf,0xf8ff-0xf8ff irq 17
at device 0.0 on pci4
re0: Using 1 MSI-X message
re0: Chip rev. 0x3c00
re0: MAC rev. 0x0040
miibus0: MII bus on re0
rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0
rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow,
1000baseT-FDX-flow-master, auto, auto-flow
re0: Ethernet address: 00:21:85:1c:24:fa
devinfo -rv | grep rgephy
rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1
This link connected to Realtek 8111E under Win7.
I'll repeat that when it's connected to sk0, everything works. Of
e1000phy(4) supports automatic crossover detection/correction. I
thought newer RealTek 8211 PHYs also support the feature but it
seems it's not enabled by default. Could you try attached patch and
let me know how it goes?
Attached patch.
Index: sys/dev/mii/rgephy.c
===
--- sys/dev/mii/rgephy.c (revision 248449)
+++ sys/dev/mii/rgephy.c (working copy)
@@ -488,7 +488,7 @@ rgephy_load_dspcode(struct mii_softc *sc)
static void
rgephy_reset(struct mii_softc *sc)
{
- uint16_t ssr;
+ uint16_t pcr, ssr;
if ((sc-mii_flags MIIF_PHYPRIV0) == 0 sc-mii_mpd_rev == 3) {
/* RTL8211C(L) */
@@ -499,6 +499,15 @@ rgephy_reset(struct mii_softc *sc)
}
}
+ if (sc-mii_mpd_rev = 2) {
+ pcr = PHY_READ(sc, RGEPHY_MII_PCR);
+ if ((pcr RGEPHY_PCR_MDIX_AUTO) == 0) {
+ pcr = ~RGEPHY_PCR_MDI_MASK;
+ pcr |= RGEPHY_PCR_MDIX_AUTO;
+ PHY_WRITE(sc, RGEPHY_MII_PCR, pcr);
+ }
+ }
+
mii_phy_reset(sc);
DELAY(1000);
rgephy_load_dspcode(sc);
Index: sys/dev/mii/rgephyreg.h
===
--- sys/dev/mii/rgephyreg.h (revision 248449)
+++ sys/dev/mii/rgephyreg.h (working copy)
@@ -137,6 +137,16 @@
#define RGEPHY_EXTSTS_T_FD_CAP 0x2000 /* 1000base-T FD capable */
#define RGEPHY_EXTSTS_T_HD_CAP 0x1000 /* 1000base-T HD capable */
+#define RGEPHY_MII_PCR 0x10 /* PHY Specific control register */
+#define RGEPHY_PCR_ASSERT_CRS 0x0800
+#define RGEPHY_PCR_FORCE_LINK 0x0400
+#define RGEPHY_PCR_MDI_MASK 0x0060
+#define RGEPHY_PCR_MDIX_AUTO 0x0040
+#define RGEPHY_PCR_MDIX_MANUAL 0x0020
+#define RGEPHY_PCR_MDI_MANUAL 0x
+#define RGEPHY_PCR_CLK125_DIS 0x0010
+#define RGEPHY_PCR_JABBER_DIS 0x0001
+
/* RTL8211B(L)/RTL8211C(L) */
#define RGEPHY_MII_SSR 0x11 /* PHY Specific status register */
#define RGEPHY_SSR_S1000
