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: 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: 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: 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: 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
A few problems
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. I tried to disable swap and reboot but it's still the same output. And here goes dmidecode: SMBIOS 2.5 present. 72 structures occupying 2730 bytes. Table at 0x000FB710. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: V3.4 Release Date: 03/09/2009 Address: 0xF Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25/1.2 MB floppy services are supported (int 13h) 3.5/720 kB floppy services are supported (int 13h) 3.5/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.15 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD Product Name: MS-7512 Version: 1.0 Serial Number: To Be Filled By O.E.M. UUID: ----0021851C24FA Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: To Be Filled By O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD Product Name: P45 Neo2-FR (MS-7512) Version: 1.0 Serial Number: To be filled by O.E.M. Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD Type: Desktop Lock: Not Present Version: 1.0 Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 40 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Core 2 Duo Manufacturer: Intel ID: 7A 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 23, Stepping 10 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM
RE: a few problems with 6.0-RELEASE on IBM T41p
Not if you're using any third party modules. What does 'kldstat' tell you? kernel + acpi.ko + linux.ko, as I already mentioned in another email. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
a few problems with 6.0-RELEASE on IBM T41p
Hi, since I've upgraded from 6.0-BETA4 to 6.0-RELEASE (using binary upgrade on contrary to 6.0-BETA4, which was binary from BETA2, which was clean install ;-) ), I'm experiencing multiple problems which were not present on BETA4: 1) when rebooting, the system freezes on message Shutting down ACPI and looks like intending to never reboot 2) I get rather regular freezes in X when running GL with drm acceleration; I've rebuilt both xorg-server-snap and dri-devel from sources but it freezes still after couple of seconds of glxgears (while it worked fine on BETA4 achieving slightly above 2100 fps) 3) psm0: unable to allocate IRQ when both psm and acpi_ibm are present in the kernel; this is also described also in one of my recent posts: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=607372+0+archive/2005/freebsd-stabl e/20051113.freebsd-stable 4) ipw (with internal 2100B card) can freeze the machine under load on rather rare occasions There are also other problems with ipw, as it sometimes ceases to work under heavier load (without freezing the system). But that was also occuring on BETA2 - BETA4. Alas none of those situations produces kernel panic, so there is no dump to send :( Any ideas? Looks to me like there is some significant problem with ACPI... (should I cross-post this to acpi@ ?) Thanks, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a few problems with 6.0-RELEASE on IBM T41p
On Mon, Nov 14, 2005 at 05:39:52AM +0100, Petr Holub wrote: Hi, since I've upgraded from 6.0-BETA4 to 6.0-RELEASE (using binary upgrade on contrary to 6.0-BETA4, which was binary from BETA2, which was clean install ;-) ), I'm experiencing multiple problems which were not present on BETA4: 1) when rebooting, the system freezes on message Shutting down ACPI and looks like intending to never reboot 2) I get rather regular freezes in X when running GL with drm acceleration; I've rebuilt both xorg-server-snap and dri-devel from sources but it freezes still after couple of seconds of glxgears (while it worked fine on BETA4 achieving slightly above 2100 fps) Did you remember to rebuild any modules you are using when you upgraded? Kris pgpmSlQ1COmxU.pgp Description: PGP signature
RE: a few problems with 6.0-RELEASE on IBM T41p
Did you remember to rebuild any modules you are using when you upgraded? cd /sys/i386/conf/ config KLOBOUCEK cd ../compile/KLOBOUCEK make cleandepend; make depend make make install as usual. I assume that's sufficient. The only thing I'm not sure of now is the linux emulation... Thanks, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: a few problems with 6.0-RELEASE on IBM T41p
2) I get rather regular freezes in X when running GL with drm acceleration; I've rebuilt both xorg-server-snap and dri-devel from sources but it freezes still after couple of seconds of glxgears (while it worked fine on BETA4 achieving slightly above 2100 fps) Did you remember to rebuild any modules you are using when you upgraded? I've checked that linux.ko has been rebuilt as well, I have no modules in /boot/modules and also at the time of freezing X with glxgears, only kernel+acpi.ko+linux.ko are loaded. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a few problems with 6.0-RELEASE on IBM T41p
On Mon, Nov 14, 2005 at 06:02:35AM +0100, Petr Holub wrote: Did you remember to rebuild any modules you are using when you upgraded? cd /sys/i386/conf/ config KLOBOUCEK cd ../compile/KLOBOUCEK make cleandepend; make depend make make install as usual. I assume that's sufficient. Not if you're using any third party modules. What does 'kldstat' tell you? Kris pgpTJqtiV70Rq.pgp Description: PGP signature
