Re: Asus A7A266
I have an unresolved issue with XFree86-4.2.0, -stable, and an ASUS A7N266-E motherboard with integrated GeForce2 VGA, the nForce chipset. Sysinstall from the 4.5 subscription CD worked fine. But, attempting to start X freezes the system. The screen flickers one time. There is no response to the keyboard. It does not break into DDB. There is no response to the serial keyboard. # uname -a FreeBSD asus 4.5-STABLE FreeBSD 4.5-STABLE #0: Sun Apr 21 11:05:40 PDT 2002 \ root@asus:/usr/src/sys/compile/ASUS i386 With patches from Matthew Dodd ([EMAIL PROTECTED]), the system broke into DDB. I provided the output from the serial console to him, including the output from DDB and the crash dump, 21 Apr 2002 21:43:36 -0700 (PDT). So far, no resolution. I still have a copy of the email. To get the system operating, I installed an ATI Radeon 7000. The bottom line, there is a problem with ASUS and integrated GeForce2 VGA's. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Asus A7A266
On Sun, Apr 28, 2002 at 11:04:54PM -0700, Jake Bishop wrote:
> Has anyone got X working with an Asus A7A266 motherboard?
If you are using XFree4 you'll probably need the patch I committed
to -STABLE last night. I've included it below if you want to test
it.
David.
Index: sys/i386/i386/i686_mem.c
===
RCS file: /cvs/FreeBSD-CVS/src/sys/i386/i386/i686_mem.c,v
retrieving revision 1.8.2.1
diff -u -r1.8.2.1 i686_mem.c
--- sys/i386/i386/i686_mem.c30 Sep 2000 02:49:32 - 1.8.2.1
+++ sys/i386/i386/i686_mem.c28 Apr 2002 22:26:03 -
@@ -82,6 +82,8 @@
struct mem_range_desc *mrd);
static voidi686_mrfetch(struct mem_range_softc *sc);
static int i686_mtrrtype(int flags);
+static int i686_mrt2mtrr(int flags, int oldval);
+static int i686_mtrrconflict(int flag1, int flag2);
static voidi686_mrstore(struct mem_range_softc *sc);
static voidi686_mrstoreone(void *arg);
static struct mem_range_desc *i686_mtrrfixsearch(struct mem_range_softc *sc,
@@ -97,29 +99,35 @@
static int i686_mtrrtomrt[] = {
MDF_UNCACHEABLE,
MDF_WRITECOMBINE,
-0,
-0,
+MDF_UNKNOWN,
+MDF_UNKNOWN,
MDF_WRITETHROUGH,
MDF_WRITEPROTECT,
MDF_WRITEBACK
};
+#define MTRRTOMRTLEN (sizeof(i686_mtrrtomrt) / sizeof(i686_mtrrtomrt[0]))
+
+static int
+i686_mtrr2mrt(int val) {
+ if (val < 0 || val >= MTRRTOMRTLEN)
+ return MDF_UNKNOWN;
+ return i686_mtrrtomrt[val];
+}
+
/*
- * i686 MTRR conflict matrix for overlapping ranges
- *
- * Specifically, this matrix allows writeback and uncached ranges
- * to overlap (the overlapped region is uncached). The array index
- * is the translated i686 code for the flags (because they map well).
+ * i686 MTRR conflicts. Writeback and uncachable may overlap.
*/
-static int i686_mtrrconflict[] = {
-MDF_WRITECOMBINE | MDF_WRITETHROUGH | MDF_WRITEPROTECT,
-MDF_ATTRMASK,
-0,
-0,
-MDF_ATTRMASK,
-MDF_ATTRMASK,
-MDF_WRITECOMBINE | MDF_WRITETHROUGH | MDF_WRITEPROTECT
-};
+static int
+i686_mtrrconflict(int flag1, int flag2) {
+ flag1 &= MDF_ATTRMASK;
+ flag2 &= MDF_ATTRMASK;
+ if (flag1 == flag2 ||
+ (flag1 == MDF_WRITEBACK && flag2 == MDF_UNCACHEABLE) ||
+ (flag2 == MDF_WRITEBACK && flag1 == MDF_UNCACHEABLE))
+ return 0;
+ return 1;
+}
/*
* Look for an exactly-matching range.
@@ -158,7 +166,7 @@
msrv = rdmsr(msr);
for (j = 0; j < 8; j++, mrd++) {
mrd->mr_flags = (mrd->mr_flags & ~MDF_ATTRMASK) |
- i686_mtrrtomrt[msrv & 0xff] |
+ i686_mtrr2mrt(msrv & 0xff) |
MDF_ACTIVE;
if (mrd->mr_owner[0] == 0)
strcpy(mrd->mr_owner, mem_owner_bios);
@@ -170,7 +178,7 @@
msrv = rdmsr(msr);
for (j = 0; j < 8; j++, mrd++) {
mrd->mr_flags = (mrd->mr_flags & ~MDF_ATTRMASK) |
- i686_mtrrtomrt[msrv & 0xff] |
+ i686_mtrr2mrt(msrv & 0xff) |
MDF_ACTIVE;
if (mrd->mr_owner[0] == 0)
strcpy(mrd->mr_owner, mem_owner_bios);
@@ -182,7 +190,7 @@
msrv = rdmsr(msr);
for (j = 0; j < 8; j++, mrd++) {
mrd->mr_flags = (mrd->mr_flags & ~MDF_ATTRMASK) |
- i686_mtrrtomrt[msrv & 0xff] |
+ i686_mtrr2mrt(msrv & 0xff) |
MDF_ACTIVE;
if (mrd->mr_owner[0] == 0)
strcpy(mrd->mr_owner, mem_owner_bios);
@@ -196,7 +204,7 @@
for (; (mrd - sc->mr_desc) < sc->mr_ndesc; msr += 2, mrd++) {
msrv = rdmsr(msr);
mrd->mr_flags = (mrd->mr_flags & ~MDF_ATTRMASK) |
- i686_mtrrtomrt[msrv & 0xff];
+ i686_mtrr2mrt(msrv & 0xff);
mrd->mr_base = msrv & 0x000ff000LL;
msrv = rdmsr(msr + 1);
mrd->mr_flags = (msrv & 0x800) ?
@@ -222,8 +230,8 @@
flags &= MDF_ATTRMASK;
-for (i = 0; i < (sizeof(i686_mtrrtomrt) / sizeof(i686_mtrrtomrt[0])); i++) {
- if (i686_mtrrtomrt[i] == 0)
+for (i = 0; i < MTRRTOMRTLEN; i++) {
+ if (i686_mtrrtomrt[i] == MDF_UNKNOWN)
continue;
if (flags == i686_mtrrtomrt[i])
return(i);
@@ -231,6 +239,16 @@
return(-1);
}
+static int
+i686_mrt2mtrr(int flags, int oldval)
+{
+ int val;
+
+ if ((val = i686_mtrrtype(flags)) == -1)
+ return oldval & 0xff;
+ return val & 0xff;
+}
+
/*
* Update running CPU(s) MTRRs to match the ranges in the descriptor
* list.
@@ -265,7 +283,7 @@
{
struct mem_range_softc *sc = (struct mem_range_softc *)arg;
struct mem_range_desc *mrd;
-u_int64_t ms
Asus A7A266
Hello, Has anyone got X working with an Asus A7A266 motherboard? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Scratch, scratch, scratch.
I've got an interesting - not harmful - occurence here. I'm running a dual-headed system, and it's obvious which monitor is the primary (console) and which is the secondary. I ran a second X session, ran fxtv and watched clicked it into fullscreen mode. Then I went to another window and killed it. That caused that X to exit. It left all my virtual consoles on the secondary monitor. As I cycle through the virtual terminals, the one with X still has .0 and .1 where I expect them. All the others have what the boot sequence left on the console on the primary, and the virtual terminals on the secondary. Normally, I get just the opposite. This is just a minor annoyance, but I'd sure like to know how it happened, and if it can be fixed without rebooting. Thanks, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ASUS A7M266-D: enabling 'on board sound'
- Original Message - From: "Randall Hopper" <[EMAIL PROTECTED]> To: "Marc G. Fournier" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, April 28, 2002 9:17 AM Subject: Re: ASUS A7M266-D: enabling 'on board sound' > Marc G. Fournier: > | Just recently picked up an ASUS A7M266-D Motherboard with Dual: > |"(AMD Athlon(TM) MP Processor (1200.05-MHz 686-class CPU)" ... the system > |purrs like the proverbial kitten ... but the one thing that is eluding me > |so far is getting the onboard sound to work ... > ... > |pcm0: at device 4.0 on pci2 > |pcm0: cmi_attach: Cannot allocate bus resource > |device_probe_and_attach: pcm0 attach returned 6 > ... > |___device pcm0 at isa? irq 5 drq 1 flags 0x0 > > I have the original non-dual version (ASUS A7M266) with the same sound > chip: > >> dmesg | grep pcm0 >pcm0: port 0xa400-0xa4ff irq 10 at device 5.0 on pci0 > > Here's what I have on my 4.3-STABLE (circa 06/01) config: > >device pcm0 >device sbc0at isa? port 0x220 irq 5 drq 1 flags 0x15 > > The flags may be the kicker for you. That sets the 2nd (16-bit) DMA > channel IIRC. > If you have the time I would be very interested in having more information about your configuration as I am contemplating building a similar SMP system. How much memory do you have installed and what use do you have for the system? Any information much appreciated. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /var/spool/clientmqueue not being processed
jemmett> That was just a partial listing, there were Qf* files far above jemmett> that someone else replied about in a private mail. Some of the jemmett> df* files were complaining about DNS troubles I was having jemmett> earlier, so I renamed the Qf* to qf* and reran the queue and jemmett> everything is now working fine. You should check the mail logs to see why the Qf files were created in the first place. The fact that they were created points to other configuration issues that should be fixed up so the problem doesn't return. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /var/spool/clientmqueue not being processed
On Sun, 2002-04-28 at 21:34, Gregory Neil Shapiro wrote: > jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:15 dfg3S5F0UP051261 > jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:20 dfg3S5K0KY051270 > jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:25 dfg3S5P0gQ051278 > jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:30 dfg3S5U0XA051287 > jemmett> -rw-rw 1 smmsp smmsp 1398 Apr 28 02:31 dfg3S5V0Cr051293 > jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:35 dfg3S5Z0uD051299 > ... > > There are no qf files (queue control), only df (data) files. That seems > odd. Many of the df files are also the same size. Did you take a look at > what is in the df files? Did you check your mail logs? > That was just a partial listing, there were Qf* files far above that someone else replied about in a private mail. Some of the df* files were complaining about DNS troubles I was having earlier, so I renamed the Qf* to qf* and reran the queue and everything is now working fine. *slaps forehead*. Thanks for the help. -- Jon Emmett [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /var/spool/clientmqueue not being processed
jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:15 dfg3S5F0UP051261 jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:20 dfg3S5K0KY051270 jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:25 dfg3S5P0gQ051278 jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:30 dfg3S5U0XA051287 jemmett> -rw-rw 1 smmsp smmsp 1398 Apr 28 02:31 dfg3S5V0Cr051293 jemmett> -rw-rw 1 smmsp smmsp 1404 Apr 28 02:35 dfg3S5Z0uD051299 ... There are no qf files (queue control), only df (data) files. That seems odd. Many of the df files are also the same size. Did you take a look at what is in the df files? Did you check your mail logs? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
