Re: Annoucning DragonFly BSD!

2003-07-17 Thread Matthew Reimer
Julian Stacey wrote:
Periodicaly someone masquerades as Matt Dilllon.  Those targeted
by trolls need to work extra hard to establish credibility of
poster's address, to avoid suspicion of "troll at work" (phone
number maybe?).  Trolls of course need to work extra hard too, to
also convince us. Maybe this time the poster is the real Matthew
Dillon, but I doubt it.
This is the real thing. The hostname apollo.backplane.com is known to be 
Matt's, and www.dragflybsd.org points to what is probably the same subnet:

$ host apollo.backplane.com
apollo.backplane.com has address 216.240.41.2
apollo.backplane.com mail is handled (pri=10) by apollo.backplane.com
$ host www.dragonflybsd.org
www.dragonflybsd.org is a nickname for crater.dragonflybsd.org
crater.dragonflybsd.org has address 216.240.41.25
crater.dragonflybsd.org mail is handled (pri=10) by crater.dragonflybsd.org
Matt

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: NVidia driver stability?

2003-07-11 Thread Matthew Reimer
Kenneth Culver wrote:
I don't know if this is relevant, but the NVidia drivers won't work with
libkse or libthr, because it messes with the %gs segment register, which
both threading libraries use. The only threading library it currently
works with is libc_r.


Actually from what I hear that's not accurate. It only works with the
linuxthreads port.
FWIW, the patch below (from doc/machdep.c.diff in the port) makes the 
drivers work fine on my -stable box, even with KDE GL apps. I'm also 
building the nvidia port with WITH_FREEBSD_AGP=yes WITH_NVIDIA_HACKS=yes.

Matt

Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.385.2.28
diff -d -u -r1.385.2.28 machdep.c
--- machdep.c   22 Jan 2003 20:14:52 -  1.385.2.28
+++ machdep.c   8 May 2003 20:05:06 -
@@ -742,8 +742,6 @@
regs->tf_cs = _ucodesel;
regs->tf_ds = _udatasel;
regs->tf_es = _udatasel;
-   regs->tf_fs = _udatasel;
-   load_gs(_udatasel);
regs->tf_ss = _udatasel;
 }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc)

2000-05-19 Thread Matthew Reimer

Greg Lehey wrote:
> 
> As far as soft updates goes, basically it's incompatible with Vinum,
> since there's currently no way of ensuring the sequence of writes
> across a number of disks.  I'm thinking of ways of doing it, but they
> will cause significant loss in performance.  There should be no
> problems as long as there isn't a crash, of course :-)

Do you mean that softupdates is entirely incompatible with Vinum, or
just incompatible with Vinum's RAID5?

Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: PATCH: partial fix for PR 16587 can't record with CS423x

2000-02-23 Thread Matthew Reimer

Doh! Sorry, I reversed the patch.

Matt

Matthew Reimer wrote:
> 
> Partial fix: the following patch correctly configures the card for dual
> channel DMA. The problem was that the SDC bit (0x04) can only be set in
> the MCE state.
> 
> So now recording doesn't hang, and data is returned, but the recorded
> sound doesn't sound right when played back. Anybody have an idea why?
> 
> --- mss.c.orig  Wed Feb 23 11:04:23 2000
> +++ mss.c   Fri Jan 28 16:18:28 2000
> @@ -92,8 +92,6 @@
>  static int ad_read(struct mss_info *mss, int reg);
>  static voidad_write(struct mss_info *mss, int reg, u_char
> data);
>  static voidad_write_cnt(struct mss_info *mss, int reg,
> u_short data
> -static voidad_enter_MCE(struct mss_info *mss);
> -static voidad_leave_MCE(struct mss_info *mss);
> 
>  /* io primitives */
>  static voidconf_wr(struct mss_info *mss, u_char reg, u_char
> data);
> @@ -467,9 +465,7 @@
> }
> if (FULL_DUPLEX(mss) && mss->bd_id != MD_OPTI931)
> ad_write(mss, 12, ad_read(mss, 12) | 0x40); /* mode 2 */
> -   ad_enter_MCE(mss);
> ad_write(mss, 9, FULL_DUPLEX(mss)? 0 : 4);
> -   ad_leave_MCE(mss);
> ad_write(mss, 10, 2); /* int enable */
> io_wr(mss, MSS_STATUS, 0); /* Clear interrupt status */
> /* the following seem required on the CS4232 */
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-multimedia" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



PATCH: partial fix for PR 16587 can't record with CS423x

2000-02-23 Thread Matthew Reimer

Partial fix: the following patch correctly configures the card for dual
channel DMA. The problem was that the SDC bit (0x04) can only be set in
the MCE state.

So now recording doesn't hang, and data is returned, but the recorded
sound doesn't sound right when played back. Anybody have an idea why?

--- mss.c.orig  Wed Feb 23 11:04:23 2000
+++ mss.c   Fri Jan 28 16:18:28 2000
@@ -92,8 +92,6 @@
 static int ad_read(struct mss_info *mss, int reg);
 static voidad_write(struct mss_info *mss, int reg, u_char
data);
 static voidad_write_cnt(struct mss_info *mss, int reg,
u_short data
-static voidad_enter_MCE(struct mss_info *mss);
-static voidad_leave_MCE(struct mss_info *mss);

 /* io primitives */
 static voidconf_wr(struct mss_info *mss, u_char reg, u_char
data); 
@@ -467,9 +465,7 @@
}
if (FULL_DUPLEX(mss) && mss->bd_id != MD_OPTI931)
ad_write(mss, 12, ad_read(mss, 12) | 0x40); /* mode 2 */
-   ad_enter_MCE(mss);
ad_write(mss, 9, FULL_DUPLEX(mss)? 0 : 4);
-   ad_leave_MCE(mss);
ad_write(mss, 10, 2); /* int enable */
io_wr(mss, MSS_STATUS, 0); /* Clear interrupt status */
/* the following seem required on the CS4232 */


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Can't record with newpcm & CS423x

2000-02-08 Thread Matthew Reimer

With my Acer AW35/Pro (CS4236) and -current I can play sound just fine,
but I can't record. (Recording and full duplex worked fine with
3.4-stable.)

When I run

rec -c 1 -f s -r 44100 -s w test.wav

rec just sits, blocked in pcmrd, and rec can't be interrupted with
ctl-c. The output file test.wav never increases in size, always
remaining 0 bytes long.

My kernel config file has "device pcm".

Any ideas?

Matt

-

cat /dev/sndstat 
FreeBSD Audio Driver (newpcm) Feb  4 2000 14:51:04
Installed devices:
pcm0:  at io 0x534 irq 5 drq 1:0 (1p/1r channels duplex)

-

FreeBSD 4.0-CURRENT #0: Fri Feb  4 14:52:00 PST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/BILBO
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (451.02-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
 
Features=0x383f9ff
real memory  = 134205440 (131060K bytes)
avail memory = 126857216 (123884K bytes)
Preloaded elf kernel "kernel" at 0xc0316000.
Pentium Pro MTRR support enabled
npx0:  on motherboard
npx0: INT 16 interface
apm0:  on motherboard
apm: found APM BIOS v1.2, connected at v1.2
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on
pci0
pci1:  on pcib1
vga-pci0:  mem
0xe200-0xe3ff,0xe0
00-0xe0ff irq 11 at device 0.0 on pci1
isab0:  at device 4.0 on pci0
isa0:  on isab0
ata-pci0:  port 0xd800-0xd80f at device
4.1 on pc
i0
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086,
dev=0x7112) at 4.2
 irq 10
chip1:  port 0xe800-0xe80f at
device 
4.3 on pci0
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd000-0xd07f mem
0xdf80-0xdf80
007f irq 10 at device 9.0 on pci0
xl0: Ethernet address: 00:10:5a:ab:87:55
miibus0:  on xl0
xlphy0: <3Com internal media interface> on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on
isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0:  at port 0x60-0x6f on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model MouseMan+, device ID 0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on
isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppi0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
pcm0:  at port 0x534-0x537,0x388-0x38f,0x220-0x22f irq 5 drq 1,0
on isa0
joy0:  at port 0x200-0x207 on isa0
unknown0:  at port 0x120-0x127 on isa0
unknown1:  at port 0x330-0x331 irq 9 on isa0
IPsec: Initialized Security Association Processing.
ad0: 8223MB  [16708/16/63] at ata0-master using UDMA33
acd0: CDROM  at ata1-master using PIO4
Mounting root from ufs:/dev/ad0s1a

-

pnpinfo:

Card assigned CSN #1
Vendor ID CSCd937 (0x37d9630e), Serial Number 0x
PnP Version 1.0, Vendor Version 1
Device Description: AW35/Pro (Resource R2.2-D7)

Logical Device ID: CSC 0x630e #0
Device Description: WSS/SB
TAG Start DF
Good Configuration
DMA: channel(s) 1 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5  - only one type (true/edge)
I/O Range 0x534 .. 0x534, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8
[16-bit addr]
I/O Range 0x220 .. 0x220, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 1 3 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x8
[16-bit addr]
I/O Range 0x220 .. 0x260, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Sub-optimal Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x3f8, alignment 0x8, len 0x8
[16-bit addr]
I/O Range 0x220 .. 0x300, alignment 0x20, len 0x10
[16-bit addr]
TAG End DF

Logical Device ID: CSC0001 0x0100630e #1
Device Description: GAME
TAG Start DF
Good Configuration
I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8
[16-bit addr]
TAG Start DF
Acceptable Configuration
I/O Range 0x208 .. 0x208, alignment 0x8, len 0x8
[16-bit addr]
TAG End DF

Logical Device ID: CSC0010 0x1000630e #2
Device Description: CTRL
I/O

Re: Serious server-side NFS problem

1999-12-16 Thread Matthew Reimer

Matt, you are a tenacious, fearsome bug hunter!

Matt

Matthew Dillon wrote:
> 
> Here's a general update on this bug report to -current.  It took all day
> but I was finally able to reproduce Andrew's bug.
> 
> You guys are going to *love* this.
> 
> NFS uses the kernel 'boottime' structure to generate its version id.
> Now normally you might believe that this structure, once set, will
> never change.  The authors of NFS certainly make that assumption!
> 
> No such luck.  If you happen to be running, oh, xntpd for example,
> the kernel adjusts the boottime structure to take into account time
> changes, including PLL changes so, in fact, the boottime structure
> can change quite often - once each tick, in fact.
> 
> Now, the effect of boottime changing on NFS is rather drastic.  You
> see, the version id controls whether NFS clients must reset their
> state machines for NFS data writes.  If a client has done a stage 1
> write and is ready to do the stage 2 commit, and the version id
> changes, the client must revert back to stage 1.
> 
> And so Andrews bug report comes into the light!   His poor client
> (and mine once I reproduced the bug) got into a state, due to the
> server returning a different version id for virtually every packet,
> where it resent the same write data over the network over and over
> and over and over and over again.
> 
> I think recent changes to the way the kernel clocks work in -current
> brought the bug out into the open, but it's definitely a problem in
> both -stable and -current.
> 
> Doh!  I gotta say that if I hadn't happened to have been running xntpd
> on my test box I would have *never* figured it out.
> 
> -Matt
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Communicator 4 and LDAP

1999-09-08 Thread Matthew Reimer

Maybe the code is trying to bind the local side of the socket to port
0x5B? If so, then it could be proved by running Netscape as root.

Matt

Amancio Hasty wrote:
> 
> Don't know what the problem is with netscape.
> 
> I can search the ldap server with openldap's ldapsearch tool:
> 
> /usr/local/openldap/bin/ldapsearch -h ldap.infospace.com -b "c=US" "cn=Amancio*"
> 
> And what do you know I am listed there 8)
> 
> cn=Amancio Hasty+ [EMAIL PROTECTED]; c=US; o=Amancio Hasty Jr; l=San Franci
> sco; st=CA; ou=
> objectclass=Person
> commonname=Amancio Hasty
> [EMAIL PROTECTED]
> cn=Amancio Hasty
> [EMAIL PROTECTED]
> surname=Hasty
> sn=Hasty
> c=US
> l=San Francisco
> st=CA
> o=Amancio Hasty Jr
> ou=
> title=
> description=
> postalAddress=
> telephonenumber=
> userPassword=
> userCertificate=
> givenname=Amancio
> facsimileTelephoneNumber=
> 
> --
> 
>  Amancio Hasty
>  [EMAIL PROTECTED]
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: solid NFS patch #6 avail for -current - need testers files)

1999-04-21 Thread Matthew Reimer
Great work guys! It almost seems that -current is more stable than
-stable!

Matt


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message