Re: load spike strangeness
> > Indeed, I could adduser bknowels and use/be Brad Knowels (for all you know > my name could also be Brad Knowels) if he prefers. I'm not like that though. > Some people just aren't happy if they aren't complaining about something. I agree. It would be nice if this thread would die. I have seen "FreeBSD" posting to lists for a while now and never saw anyone else complain. If you don't like it, just filter him out of your inbox, but please...there's been too much cat fighting on this list lately. > > > > Amancio Hasty > > [EMAIL PROTECTED] > > > > FreeBSD > [EMAIL PROTECTED] > > "LinSUX is only free if your time is worthless" > > 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: pcm - stutters
On Tue, 25 Jan 2000, Donn Miller wrote: > Nick Hibma wrote: > > > The output of my ESS 1869 stutters whenever there is no new data fed to > > it. For example pressing Ctrl-Z, or heavy disk usage (normally making > > mpg123 jump). The stuttering is repetition of one short fragment of > > about a quarter of a second, indefinitely > > I can confirm this. Whenever there is any substantial disk activity, > the output of mpg123 starts to jump and quiver (and sometimes skip). > Why would disk activity do this? Must be an issue with bus latency, > because the ata and sound driver are trying to access the bus at the > same time. Also, it seems like certain graphics ops in XFree86 3.9.17 > make mpg123 jump and skip. Strangely, RealPlayer doesn't suffer from > these problems. I too notice these problems of mpg123 skipping during disk activity or X graphics ops but I have always had these problems, both with -STABLE and -CURRENT. I notice this with xmms too. So this is nothing new. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Error: no such 386 instruction: `state' ???
Hi,
I'm running a snap from 2/28:
FreeBSD dbm.wireless.net 4.0-2228-CURRENT FreeBSD 4.0-2228-CURRENT #2:
Fri Mar 3 22:19:33 PST 2000
Often when compiling a port, the process will fail with messages like
the following:
[...]
Compiling smbd/noquotas.c
Compiling smbd/reply.c
{standard input}: Assembler messages:
{standard input}:4939: Error: no such 386 instruction: `state'
*** Error code 1
Stop in /usr/ports/net/samba/work/samba-2.0.6/source.
*** Error code 1
Stop in /usr/ports/net/samba.
*** Error code 1
Stop in /usr/ports/net/samba.
*** Error code 1
Stop in /usr/ports/net/samba.
*** Error code 1
Stop in /usr/ports/net/samba.
[root@dbm /usr/ports/net/samba]#
The strange thing is, if I just say "make" again, it will continue to compile
where it left off without any problems.
Anyone else see these errors? Any Ideas?
--
Regards, Devin.
P.S. Never had this problem under 3.x.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Error: no such 386 instruction: `state' ???
Hi,
I am running a current snap from 2/28.
FreeBSD dbm.wireless.net 4.0-2228-CURRENT FreeBSD 4.0-2228-CURRENT
#2: Fri Mar 3 22:19:33 PST 2000
Often when compiling a port, the process fails with messages like the
following:
[...]
Compiling smbd/pipes.c
Compiling smbd/predict.c
Compiling smbd/noquotas.c
Compiling smbd/reply.c
{standard input}: Assembler messages:
{standard input}:4939: Error: no such 386 instruction: `state'
*** Error code 1
Stop in /usr/ports/net/samba/work/samba-2.0.6/source.
*** Error code 1
Stop in /usr/ports/net/samba.
*** Error code 1
Stop in /usr/ports/net/samba.
*** Error code 1
Stop in /usr/ports/net/samba.
*** Error code 1
Stop in /usr/ports/net/samba.
[root@dbm /usr/ports/net/samba]#
The strange thing is, if I just say make again, it will continue to compile
where it left off without any problems.
Has anyone seen messages like this before? Any ideas?
--
Regards, Devin.
P.S. I never had this problem under 3.x.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Error: no such 386 instruction: `state' ???
Oops! Sorry for the double post. :( Kmail got stupid on me... -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tunefs -p doesn't work for read-write mounts
Sheldon Hearn wrote: > > Hi folks, > > Shouldn't I be able to show the current tuneables for a given filesystem? > > # tunefs -p /usr > tunefs: cannot work on read-write mounted file system > > This is on a recent CURRENT. AFAIK, you always need to do this with unmounted file systems. Unless of course this was fixed in current? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree86 4.0 in FreeBSD 4.0?
Hi, Just wondering if there are plans in the works to get Xfree86 4.0 into FreeBSD 4.0. I just noticed that X 4.0 has finally been released. -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA driver problem?? (lost disk contact)
Hi, I just recently compiled a kernel with the new ATA driver and have discovered a problem: if I run sysinstall, right when it says "probing devices, please wait (this can be a while)" error messages saying... Dec 15 21:20:05 dbm /kernel: ata0-slave: ad_timeout: lost disk contact - resetting Dec 15 21:20:05 dbm /kernel: ata0: resetting devices .. done Dec 15 21:20:15 dbm /kernel: ata0-slave: ad_timeout: lost disk contact - resetting Dec 15 21:20:15 dbm /kernel: ata0: resetting devices .. done Dec 15 21:20:25 dbm /kernel: ata0-slave: ad_timeout: lost disk contact - resetting Dec 15 21:20:25 dbm /kernel: ata0: resetting devices .. done Dec 15 21:20:35 dbm /kernel: ata0-slave: ad_timeout: lost disk contact - resetting Dec 15 21:20:35 dbm /kernel: ata0-slave: ad_timeout: trying fallback to PIO mode Dec 15 21:20:35 dbm /kernel: ata0: resetting devices .. done and after printing these messages a number of times, sysinstall will finally come up. If I quit sysinstall and then run it again, probing goes well and there are no timeouts. The interesting thing is that I can reproduce this problem by rebooting and running sysinstall. So, this only happens when running sysinstall for the first time after a boot. :-/ I've read through all the previous messages regarding these timeout problems and have even increased the timeout in ata-disk.c to 10 secs but no luck. Anybody have any ideas?? Below is the usual info... -- Regards, Devin. Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-19991214-CURRENT #1: Wed Dec 15 21:05:38 PST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/DBM Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (501.14-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 134152192 (131008K bytes) avail memory = 126500864 (123536K bytes) Preloaded elf kernel "kernel" at 0xc0378000. md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 ata-pci0: at device 15.0 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 dc0: <82c169 PNIC 10/100BaseTX> irq 10 at device 16.0 on pci0 dc0: Ethernet address: 00:a0:cc:27:48:ec miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ad0: ATA-5 disk at ata0 as master ad0: 8297MB (16992864 sectors), 16858 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad1: ATA-4 disk at ata0 as slave ad1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, UDMA33 acd0: CDROM drive at ata1 as master acd0: read 1377KB/s (1377KB/s), 128KB buffer, PIO acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s2a cd0 at adv0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
Hi, "Dave J. Boers" wrote: > > On Thu, Dec 16, 1999 at 08:29:14AM +0100, Soren Schmidt wrote: > > It seems Devin Butterfield wrote: > > > I just recently compiled a kernel with the new ATA driver and have > > > discovered a problem: if I run sysinstall, right when it says "probing > > > devices, please wait (this can be a while)" error messages saying... > > [snip] > > > and after printing these messages a number of times, sysinstall will > > > finally come up. If I quit sysinstall and then run it again, probing > > > goes well and there are no timeouts. The interesting thing is that I can > > > reproduce this problem by rebooting and running sysinstall. So, this > > > only happens when running sysinstall for the first time after a boot. > > > > > > Hmm, I'd put my disks on different channels, but thats just for > > performance sake. I'm currently trying every wierd setup I can > > imagine with the HW I have for testing, but I havn't been able > > to get any of my test setups to exhibit this behavior... > > > > But I'm working on it... > > I am still having "disc contact lost messages" regularly too. I've been > posting about them on several occasions some time ago. [SNIP] > There are two important aspects of the problem: > > 1. The problem does not always occur: it's unpredictable > 2. When it occurs, I can actually hear the disk spinning down and then up >again. > [SNIP] That's interesting...In my case it is quite easily reproduced (very predictable). All I have to do is reboot and then run sysinstall and when it probes the devices the disks time out. So far I have not been able to get this behavior at any other time. I should also note that it repeatedly try's "resetting devices...done." many times (number of times it does this varies). Soren, since the problem is reproducible in my case, can you think of anything else I can try to help shed some light on what might be causing these time-outs we are having? Thanks again! -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? Solution (in my case)!
Hi Soren/group, After spending a little time sniffing around in my BIOS I realized that my BIOS (Award BIOS) defaults to disabling UDMA for both master and slave and for some reason I never thought to check thisduh. Anyway after setting this to "auto" for both master and slave the problem seems to be fixed! This is curious because I was running the wd driver with the BIOS set wrong all along and never had any errors or problems (AFAIK). So why does the wd driver seem to ignore this incorrect configuration while the ata driver trips over it? Does this help anyone? Thanks again for your help Soren/everyone else. -- Regards, Devin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? Solution (in my case)!
Hi Soren, No unfortunately it still fails with the patch and the UDMA disabled in the BIOS. I'd be happy to try anything else you can think of. :) Thanks. -- Regards, Devin. Soren Schmidt wrote: > > It seems Devin Butterfield wrote: > > Hi Soren/group, > > > > After spending a little time sniffing around in my BIOS I realized that > > my BIOS (Award BIOS) defaults to disabling UDMA for both master and > > slave and for some reason I never thought to check thisduh. Anyway > > after setting this to "auto" for both master and slave the problem seems > > to be fixed! > > > > This is curious because I was running the wd driver with the BIOS set > > wrong all along and never had any errors or problems (AFAIK). So why > > does the wd driver seem to ignore this incorrect configuration while the > > ata driver trips over it? > > > > Does this help anyone? > > Hmm, maybe. > > Try the below patch, but with the BIOS again in the disabled position, > and see if it still fails. > > Index: ata-dma.c > === > RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v > retrieving revision 1.23 > diff -u -r1.23 ata-dma.c > --- ata-dma.c 1999/12/14 10:25:25 1.23 > +++ ata-dma.c 1999/12/16 10:44:51 > @@ -227,6 +227,12 @@ > pci_write_config(scp->dev, 0x53, > pci_read_config(scp->dev, 0x53, 1) | 0x03, 1); > scp->flags |= ATA_ATAPI_DMA_RO; > + if (device == ATA_MASTER) > + outb(scp->bmaddr + ATA_BMSTAT_PORT, > + inb(scp->bmaddr + ATA_BMSTAT_PORT) | ATA_BMSTAT_DMA_MASTER); > + else > + outb(scp->bmaddr + ATA_BMSTAT_PORT, > + inb(scp->bmaddr + ATA_BMSTAT_PORT) | ATA_BMSTAT_DMA_SLAVE); > scp->mode[(device == ATA_MASTER) ? 0 : 1] = ATA_MODE_UDMA2; > return 0; > } > @@ -242,6 +248,12 @@ > pci_write_config(scp->dev, 0x53, > pci_read_config(scp->dev, 0x53, 1) | 0x03, 1); > scp->flags |= ATA_ATAPI_DMA_RO; > + if (device == ATA_MASTER) > + outb(scp->bmaddr + ATA_BMSTAT_PORT, > + inb(scp->bmaddr + ATA_BMSTAT_PORT) | ATA_BMSTAT_DMA_MASTER); > + else > + outb(scp->bmaddr + ATA_BMSTAT_PORT, > + inb(scp->bmaddr + ATA_BMSTAT_PORT) | ATA_BMSTAT_DMA_SLAVE); > scp->mode[(device == ATA_MASTER) ? 0 : 1] = ATA_MODE_WDMA2; > return 0; > } > > -Søren > > 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: Sound and -current.
Julian Elischer wrote: > > So is there any chance that my Vibra16 Soundblaster will ever be > recognised again? > > I was surprised because I had imagined that the soundblaster would be the > first card supported under the new code. > > unknown0: at port 0x220-0x22f,0x300-0x301,0x388-0x38b irq 7 drq > 0,5 on isa0 > unknown1: at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0 > unknown2: at port 0x200-0x207 on isa0 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Silly question but...do you have: device pcm0 device sbc0 in your kernel config? I have the ViBRA16X and I got the same messages during boot until I compiled support into the kernel. Now it looks like: sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq1,3 on isa0 pcm0: on sbc0 unknown0: at port 0x201 on isa0r Of course I'm not using the game port. :) -- Regards, Devin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
