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 :
> > > 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=8843 metric 0 mtu 1500
> > >> description: ToISP
> > >>
> > >> options=8218b
> > >> ether 00:21:85:1c:24:fa
> > >> media: Ethernet autoselect (100baseTX )
> > >> 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: 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: on re0
> > rgephy0: 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 */
#def
Re: A few problems
On Mon, Mar 18, 2013 at 05:19:11PM +0400, Michael BlackHeart wrote: > 2013/3/18 YongHyeon PYUN : > > 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=8843 metric 0 mtu 1500 > >> description: ToISP > >> > >> options=8218b > >> ether 00:21:85:1c:24:fa > >> media: Ethernet autoselect (100baseTX ) > >> 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: 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: on re0 > rgephy0: 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: port 0xe800-0xe8ff mem > 0xfebec000-0xfebe irq 17 at device 1.0 on pci5 > skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) > sk0: on skc0 > sk0: Ethernet address: 00:19:5b:86:3b:53 > miibus1: on sk0 > e1000phy0: 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
2013/3/18 Chuck Swiger : > 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
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 YongHyeon PYUN : > 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=8843 metric 0 mtu 1500 >> description: ToISP >> >> options=8218b >> ether 00:21:85:1c:24:fa >> media: Ethernet autoselect (100baseTX ) >> 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: 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: on re0 rgephy0: 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: port 0xe800-0xe8ff mem 0xfebec000-0xfebe irq 17 at device 1.0 on pci5 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:19:5b:86:3b:53 miibus1: on sk0 e1000phy0: 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 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=8843 metric 0 mtu 1500 > description: ToISP > > options=8218b > ether 00:21:85:1c:24:fa > media: Ethernet autoselect (100baseTX ) > 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"
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) T
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]"
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
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
> 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
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
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]"
