Re: Strange pcm/network problem
On Dec 03, Peter Hofer wrote: > Mathew Kanner wrote: > > > I notice that your network cards, sound card and sio use IRQ > >4, I also note that your aren't using acpi, what happens when you > >enable it? > > > You're right, it was because of ACPI ;) > > I just compiled a GENERIC kernel and booted it with ACPI ENABLED. > The problem didn't occur. Then, I booted it with ACPI DISABLED, > and the problem was there again. > Good news, please supply a dmesg before and after. Thanks, --mat -- I don't even know what street Canada is on. - Al Capone ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to disable devices in -current / 5.2-BETA?
On Dec 02, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Scott Long <[EMAIL PROTECTED]> writes: > : However, having a general mechanism for disabling newbus devices would be > : really nice. > > Agreed. But today and 5.2 you lose. However, it isn't easy. What > does disabled mean? Don't attach? Don't even probe? If you don't > probe, then how do you know that the device is aac.0? If you do > probe, then you get ISA probe routines called that can be > 'destructive'. 2 cents from a newbie. Have a pci_null driver that uses a tunable to probe and match at a higher priority. You would have to know what you are looking for to avoid it, but for someone who knows what they are doing, it would work. Please don't shoot me for being stupid :) --mat -- The state has no business in the bedrooms of the nation. - Pierre Elliott Trudeau ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange pcm/network problem
Peter, I'm afraid I haven't a clue why this happens to you but please see my notes below. On Dec 03, Peter Hofer wrote: > since I installed 5.2-BETA, I've got a very strange problem. Always > when I'm listening to some music and start a network transfer, both > the music and the transfer stop after some time. Nothing is being > received or sent any more, and the following message appears a few > times: > > bfe0: watchdog timeout -- resetting > > This goes on until I exit xmms. When I exit xmms, after a few seconds > the network works again. There's no problem in receiving and sending > data then. > > I was able to reproduce this with mpg123, it just stops playing and > exits when data is being sent over the network. And dmesg then says "pcm channel dead" ? > > The problem also persists when I'm using my rl nic instead of the > onboard bfe chip. > > I'm using sources from yesterday (2003-11-02) now and this problem > still occurs, no matter if sound support is loaded with kldload or > compiled into the kernel. No need to try compiling PCM in the kernel, klds should work exactly the same. I notice that your network cards, sound card and sio use IRQ 4, I also note that your aren't using acpi, what happens when you enable it? A brief look at the ich code reveals that it's flagged as mpsafe when it isn't, but since you are UP, I don't see this being the cause. I also vaguely remember that another OS had a note about certain corner cases missing interrupts but I don't think that should affect other irq handlers either. I really am stumped. If we can't figure this out, you always do a binary search to find the commit that caused it, though since I wouldn't likely do this myself, I wouldn't expect you to. Input from others warmly received :) --mat -- Any idiot can face a crisis; it is this day-to-day living that wears you out. - Chekhov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: please test pcm channel patch
On Dec 03, Sean Chittenden wrote:
> > > Hello All,
> > > Please test this PCM patch. It creates seperate locking
> > > classes for PCM channels and should prevent the warning where
> > > multiple mutexes from the same class are held (as reported
> > > recently). I believe this to be a good strategy as it masks fewer
> > > errors.
> >
> > I can confirm that this patch fixes my LOR for pcm(4). -sc
>
> Bah! I got 30min into playing tunes and picked the same LOR up not
> more than 5min after sending this. :( Sorry for the false alarm.
>
> acquiring duplicate lock of same type: "pcm record channel"
> 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:144
> 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:146
> Stack backtrace:
Sean,
I found the mistake, I assumed that a variable was initialized
when it wasn't. Sorry for asking you to test a stupid patch before.
Please try this one.
Thanks again,
--Mat
--
Having your book made into a movie is like having your ox
made into a bouillon cube.
- Bill Neely
Index: channel.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v
retrieving revision 1.92
diff -u -r1.92 channel.c
--- channel.c 27 Nov 2003 19:51:44 - 1.92
+++ channel.c 3 Dec 2003 16:55:41 -
@@ -67,9 +67,12 @@
static int chn_buildfeeder(struct pcm_channel *c);
static void
-chn_lockinit(struct pcm_channel *c)
+chn_lockinit(struct pcm_channel *c, int dir)
{
- c->lock = snd_mtxcreate(c->name, "pcm channel");
+ if (dir == PCMDIR_PLAY)
+ c->lock = snd_mtxcreate(c->name, "pcm play channel");
+ else
+ c->lock = snd_mtxcreate(c->name, "pcm record channel");
}
static void
@@ -736,7 +739,7 @@
struct snd_dbuf *b, *bs;
int ret;
- chn_lockinit(c);
+ chn_lockinit(c, dir);
b = NULL;
bs = NULL;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: please test pcm channel patch
On Dec 03, Sean Chittenden wrote: > > > Hello All, > > > Please test this PCM patch. It creates seperate locking > > > classes for PCM channels and should prevent the warning where > > > multiple mutexes from the same class are held (as reported > > > recently). I believe this to be a good strategy as it masks fewer > > > errors. > > > > I can confirm that this patch fixes my LOR for pcm(4). -sc > > Bah! I got 30min into playing tunes and picked the same LOR up not > more than 5min after sending this. :( Sorry for the false alarm. > > acquiring duplicate lock of same type: "pcm record channel" > 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:144 > 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/dsp.c:146 > Stack backtrace: Bah indeed. Gotta think some more. Thanks, --mat -- Any idiot can face a crisis; it is this day-to-day living that wears you out. - Chekhov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
please test pcm channel patch
Hello All,
Please test this PCM patch. It creates seperate locking
classes for PCM channels and should prevent the warning where multiple
mutexes from the same class are held (as reported recently). I
believe this to be a good strategy as it masks fewer errors.
Thanks,
--mat
--
The state has no business in the bedrooms of the
nation.
- Pierre Elliott Trudeau
Index: channel.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v
retrieving revision 1.92
diff -u -r1.92 channel.c
--- channel.c 27 Nov 2003 19:51:44 - 1.92
+++ channel.c 3 Dec 2003 05:59:56 -
@@ -69,7 +69,10 @@
static void
chn_lockinit(struct pcm_channel *c)
{
- c->lock = snd_mtxcreate(c->name, "pcm channel");
+ if (c->direction == PCMDIR_PLAY)
+ c->lock = snd_mtxcreate(c->name, "pcm play channel");
+ else
+ c->lock = snd_mtxcreate(c->name, "pcm record channel");
}
static void
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-BETA dsp.c duplicate lock
On Dec 02, Mathew Kanner wrote: > On Dec 01, Maxime Henrion wrote: > [snip] > I believe that your patch should fix the problem. In general > I see one of three strategies, > > 1)Your patch, > 2)create a new snd_mtxcreate_chan for channels that sets the > flags DUP_OK. > 3)Fix locking to never hold duplicates. First glance suggests > that would be contained in dsp.c, the ioctl handler is the real > problem and seems inconsistent with itself in regards to locking. > Ugh. Why do the best ideas happen after you send? 4) Make read and write channel locks of a different class. --Mat -- In general, a standard is very useful, whether it's de facto or du jour. - Microsoft's Greg Sullivan as misquoted by News.Com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-BETA dsp.c duplicate lock
On Dec 01, Maxime Henrion wrote: > Mathew Kanner wrote: > [patch ripped] > > > > Maxime, > > I think it would be better to isolate the changes (DUP_OK flag > > and lock creation) to just the channel code, no need to touch every > > driver. > > Yes, but to do this I'd need either to make the channel code use > mtx_init() directly, which would defeat the purpose of the USING_MUTEX > define, or to completely unifdef -U it. Since I had no idea if this code > was actually used or not, I went the safe way and just changed the > snd_mtxcreate() wrapper interface to accept mutex options. For what it's > worth, there is at least one direct invokation of mtx_init() in the sound > drivers, so it seems this define is actually already broken. Funny, I was thinking the exact same thing the other day. I'm %100 for this idea. > This needs to be sorted out before committing this patch if we need to, > but for now, I just wanted to see if using MTX_DUPOK solved the problem or > not. I believe that your patch should fix the problem. In general I see one of three strategies, 1) Your patch, 2) create a new snd_mtxcreate_chan for channels that sets the flags DUP_OK. 3) Fix locking to never hold duplicates. First glance suggests that would be contained in dsp.c, the ioctl handler is the real problem and seems inconsistent with itself in regards to locking. Ugh. > > > Also, if this is the right direction, we should back out the > > commit I did that re-ordered code that prevented duplicate channel > > locks (obviously it wasn't completen) channel. > > If the code is not supposed to acquire several channel locks at once, > then yes, it's not the right direction to go.As I said in my previous > mail, and that's why I wanted the advice of you sound guys, in that case > it's just a workaround. :-) I hear you. The fact is, currently there are no experienced sound people. Anyway, my order of preference is #2, #3, #1. Since #1 exists, I don't mind it being committed until we really understand what's going on. I will work on #3 tonight and maybe fallback to #2. Cheers, --Mat -- Applicants must also have extensive knowledge of UNIX, although they should have sufficiently good programming taste to not consider this an achievement. - MIT AI Lab job ad in the /Boston Globe/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-BETA dsp.c duplicate lock
On Dec 01, Maxime Henrion wrote:
> Jesse Guardiani wrote:
> > Jesse Guardiani wrote:
> Index: isa/ad1816.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/isa/ad1816.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 ad1816.c
> --- isa/ad1816.c 7 Sep 2003 16:28:02 - 1.29
> +++ isa/ad1816.c 1 Dec 2003 14:11:45 -
> @@ -593,7 +593,8 @@ ad1816_attach(device_t dev)
> ad1816 = (struct ad1816_info *)malloc(sizeof *ad1816, M_DEVBUF, M_NOWAIT |
> M_ZERO);
> if (!ad1816) return ENXIO;
>
> - ad1816->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc");
> + ad1816->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc",
> + 0);
> ad1816->io_rid = 2;
> ad1816->irq_rid = 0;
> ad1816->drq1_rid = 0;
> Index: isa/mss.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/isa/mss.c,v
> retrieving revision 1.86
> diff -u -p -r1.86 mss.c
> --- isa/mss.c 7 Sep 2003 16:28:02 - 1.86
> +++ isa/mss.c 1 Dec 2003 14:11:53 -
> @@ -1667,7 +1667,7 @@ mss_doattach(device_t dev, struct mss_in
> int pdma, rdma, flags = device_get_flags(dev);
> char status[SND_STATUSLEN], status2[SND_STATUSLEN];
>
> - mss->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc");
> + mss->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc", 0);
> mss->bufsize = pcm_getbuffersize(dev, 4096, MSS_DEFAULT_BUFSZ, 65536);
> if (!mss_alloc_resources(mss, dev)) goto no;
> mss_init(mss, dev);
> Index: isa/sbc.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/isa/sbc.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 sbc.c
> --- isa/sbc.c 7 Feb 2003 14:05:33 - 1.38
> +++ isa/sbc.c 1 Dec 2003 14:12:03 -
> @@ -116,7 +116,8 @@ static void sb_setmixer(struct resource
> static void
> sbc_lockinit(struct sbc_softc *scp)
> {
> - scp->lock = snd_mtxcreate(device_get_nameunit(scp->dev), "sound softc");
> + scp->lock = snd_mtxcreate(device_get_nameunit(scp->dev), "sound softc",
> + 0);
> }
>
> static void
> Index: pci/cmi.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/pci/cmi.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 cmi.c
> --- pci/cmi.c 2 Sep 2003 17:30:37 - 1.23
> +++ pci/cmi.c 1 Dec 2003 14:12:15 -
> @@ -842,7 +842,7 @@ cmi_attach(device_t dev)
> return ENXIO;
> }
>
> - sc->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc");
> + sc->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc", 0);
> data = pci_read_config(dev, PCIR_COMMAND, 2);
> data |= (PCIM_CMD_PORTEN|PCIM_CMD_BUSMASTEREN);
> pci_write_config(dev, PCIR_COMMAND, data, 2);
> Index: pci/ds1.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/pci/ds1.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 ds1.c
> --- pci/ds1.c 2 Sep 2003 17:30:37 - 1.36
> +++ pci/ds1.c 1 Dec 2003 14:12:26 -
> @@ -942,7 +945,7 @@ ds_pci_attach(device_t dev)
> return ENXIO;
> }
>
> - sc->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc");
> + sc->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc", 0);
> sc->dev = dev;
> subdev = (pci_get_subdevice(dev) << 16) | pci_get_subvendor(dev);
> sc->type = ds_finddev(pci_get_devid(dev), subdev);
> Index: pci/emu10k1.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/pci/emu10k1.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 emu10k1.c
> --- pci/emu10k1.c 7 Sep 2003 16:28:03 - 1.41
> +++ pci/emu10k1.c 1 Dec 2003 14:12:35 -
> @@ -1468,7 +1468,7 @@ emu_pci_attach(device_t dev)
> return ENXIO;
> }
>
> - sc->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc");
> + sc->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc", 0);
> sc->dev = dev;
> sc->type = pci_get_devid(dev);
> sc->rev = pci_get_revid(dev);
> Index: pci/t4dwave.c
> ===
> RCS file: /space2/ncvs/src/sys/dev/sound/pci/t4dwave.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 t4dwave.c
> --- pci/t4dwave.c 7 Sep 2003 16:28:03 - 1.40
> +++ pci/t4dwave.c 1 Dec 2003 14:12:42 -
> @@ -811,7 +811,7 @@ tr_pci_attach(device_t dev)
>
> tr->type = pci_get_devid(dev);
> tr->rev = pci_get_revid(dev);
> - tr->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc");
> + tr->lock = snd_mtxcreate(device_get_nameunit(dev), "sound softc", 0);
>
> data = pci_read_config(dev, PCIR_COMMAND, 2);
> data |= (PC
Re: no /dev/dsp.x
On Nov 29, T Kellers wrote: > On Friday 28 November 2003 11:41 pm, T Kellers wrote: > > After fighting with the laptop for about an hour this morning before class, I > decided to wipe out the FreeBSD slice and start over with 5.1-RELEASE. After > that install and subsequent kernel build/install with device pcm, not only > didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko > entries in /boot/kernel. Just to make sure I wasn't dealing with a dead > maestro3, I booted into XP and, sure enough, the sound worked. > > I nuked /usr/src and /usr/obj, cvsupped the sources and the buildworld && > buildkernel && installkernel is proceeding as I type this. If this doesn't > work --and confidence is low-- I'm pretty near stumped. There is no > difference in hardware (or BIOS settings) from the identical laptop running > 4.9-STABLE. > > Ideas, suggesstions, rants welcome. Maybe you should try 5.2-BETA? Also, don't include device pcm in your kernel unless you have specific reason to, kld's should work fine. I don't recall seeing a dmesg or a cat /dev/sndstat in any of your posts, you should include them. Maybe even your loader.conf. --mat -- The state has no business in the bedrooms of the nation. - Pierre Elliott Trudeau ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nvidia problem fixed in current?
On Nov 29, Justin Smith wrote: > > [snip] > The kernel nvidia driver worked fine in 5.1. It only STOPPED working > when I upgraded to 5.2 beta (and rebuilt and reinstalled the kernel driver). > > This is a problem of 5.2 vs 5.1 something changed that stopped it > from working. Perhaps some libraries in 5.2 are no longer compatible > with the nvidia kernel driver (since it is, fundamentally, a binary > program --- one cannot recompile the core of it). > > Perhaps it's a problem with AGP in 5.2. Slowing down AGP (to 1x) allows > the nvidia driver to work but it still reboots the machine whenever I > try to do anything that involves OpenGL... > > Also, it's odd the the thing fails in such a strange manner (rebooting > the machine without any error messages). Have you tried a kernel without acpi? --Mat -- Any idiot can face a crisis; it is this day-to-day living that wears you out. - Chekhov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Time jumping on both 4.x and 5.x ...
On Nov 28, Marc G. Fournier wrote: > > In trying to isolate an issue where the PostgreSQL 'explain analyze' is > showing "odd results" (namely, negative time estimates on queries), Tom > Lane wrote a quick C program to test gettimeofday() (program attached) ... > the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: > > neptune# time ./timetest > out of order tv_sec: 1070068479 99040, prev 1070069174 725235 > out of order tv_usec: 1070068479 99040, prev 1070069174 725235 > out of order tv_sec: 1070069175 19687, prev 1070068479 99040 > out of order tv_usec: 1070069175 19687, prev 1070068479 99040 > out of order tv_sec: 1070068499 99377, prev 1070069194 625573 > out of order tv_usec: 1070068499 99377, prev 1070069194 625573 > out of order tv_sec: 1070069194 808542, prev 1070068499 99377 > ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w > > One person on the list has tried the same script on a 5.2 kernel, and > reports seeing similar results, but after a longer period of time (~30min) > ... > > In most (all?) cases, the offset appears to be ~+/-695 secs ... Linux ppl > on the list, running the same problem, seem to be able to reproduce the > issue, except they are only finding differences of 1 microsecond, and then > only on older kernels (2.2.x, apparently) ... those running newer Linux > kernels are reporting a clean run ... FreeBSD 5.2 (up, no acpia): I get the errors only when I force heavy load and swapping. - kern.timecounter.hardware: TSC - FreeBSD tube.xx.xx5.2-BETA FreeBSD 5.2-BETA #6: Fri Nov 28 14:20:25 EST 2003 [EMAIL PROTECTED] i386 FreeBSD 4.8 (up): Didn't see the error on a nominally loaded server, I tested for about ten minutes. - kern.timecounter.hardware: i8254 - FreeBSD yy.yy.yy.yy4.8-STABLE FreeBSD 4.8-STABLE #0: Wed Jul 30 13:51:04 EDT 2003 [EMAIL PROTECTED] i386 --Mat -- sig machine boken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
please test sndstat lor patch
Hello Gang,
I wrote this to cleanup /dev/sndstat a little and fix a LOR.
Then I couldn't remember if there is a LOR or not. Could someone
please remind me? If we do, could someone please test this patch.
Thanks,
--Mat
--
The beaver, which has come to represent Canada as the eagle
does the United States and the lion Britain, is a
flat-tailed, slow-witted, toothy rodent known to bite off
it's own testicles or to stand under its own falling trees.
- June Callwood
Index: sndstat.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/sndstat.c,v
retrieving revision 1.14
diff -u -r1.14 sndstat.c
--- sndstat.c 7 Sep 2003 16:28:03 - 1.14
+++ sndstat.c 27 Nov 2003 18:21:06 -
@@ -56,44 +56,41 @@
int type, unit;
};
-#ifdef USING_MUTEX
-static struct mtx sndstat_lock;
-#endif
-static struct sbuf sndstat_sbuf;
static dev_t sndstat_dev = 0;
static int sndstat_isopen = 0;
-static int sndstat_bufptr;
+
+struct sndstat {
+ void *rawbuf;
+ struct sbuf sbuf;
+ int bufptr;
+ int isopen;
+};
+
+static struct mtx sndstat_lock;
static int sndstat_maxunit = -1;
static int sndstat_files = 0;
static SLIST_HEAD(, sndstat_entry) sndstat_devlist = SLIST_HEAD_INITIALIZER(none);
static int sndstat_verbose = 1;
-#ifdef USING_MUTEX
TUNABLE_INT("hw.snd.verbose", &sndstat_verbose);
-#else
-TUNABLE_INT_DECL("hw.snd.verbose", 1, sndstat_verbose);
-#endif
static int sndstat_prepare(struct sbuf *s);
static int
sysctl_hw_sndverbose(SYSCTL_HANDLER_ARGS)
{
- intrmask_t s;
int error, verbose;
verbose = sndstat_verbose;
error = sysctl_handle_int(oidp, &verbose, sizeof(verbose), req);
if (error == 0 && req->newptr != NULL) {
- s = spltty();
mtx_lock(&sndstat_lock);
if (verbose < 0 || verbose > 3)
error = EINVAL;
else
sndstat_verbose = verbose;
mtx_unlock(&sndstat_lock);
- splx(s);
}
return error;
}
@@ -103,32 +100,26 @@
static int
sndstat_open(dev_t i_dev, int flags, int mode, struct thread *td)
{
- intrmask_t s;
+ struct sndstat *s = i_dev->si_drv1;
int error;
- s = spltty();
+ if (s == NULL)
+ return ENXIO;
+
mtx_lock(&sndstat_lock);
if (sndstat_isopen) {
mtx_unlock(&sndstat_lock);
- splx(s);
return EBUSY;
}
- sndstat_isopen = 1;
+ sndstat_isopen = s->isopen = 1;
mtx_unlock(&sndstat_lock);
- splx(s);
- if (sbuf_new(&sndstat_sbuf, NULL, 4096, 0) == NULL) {
- error = ENXIO;
- goto out;
- }
- sndstat_bufptr = 0;
- error = (sndstat_prepare(&sndstat_sbuf) > 0) ? 0 : ENOMEM;
-out:
+ sbuf_clear(&s->sbuf);
+ s->bufptr = 0;
+ error = (sndstat_prepare(&s->sbuf) > 0) ? 0 : ENOMEM;
if (error) {
- s = spltty();
mtx_lock(&sndstat_lock);
- sndstat_isopen = 0;
+ sndstat_isopen = s->isopen = 0;
mtx_unlock(&sndstat_lock);
- splx(s);
}
return (error);
}
@@ -136,42 +127,40 @@
static int
sndstat_close(dev_t i_dev, int flags, int mode, struct thread *td)
{
- intrmask_t s;
+ struct sndstat *s = i_dev->si_drv1;
+ if (s == NULL)
+ return ENXIO;
- s = spltty();
mtx_lock(&sndstat_lock);
if (!sndstat_isopen) {
mtx_unlock(&sndstat_lock);
- splx(s);
return EBADF;
}
- sbuf_delete(&sndstat_sbuf);
- sndstat_isopen = 0;
+ sndstat_isopen = s->isopen = 0;
mtx_unlock(&sndstat_lock);
- splx(s);
return 0;
}
static int
sndstat_read(dev_t i_dev, struct uio *buf, int flag)
{
- intrmask_t s;
+ struct sndstat *s = i_dev->si_drv1;
int l, err;
- s = spltty();
+ if (s == NULL)
+ return ENXIO;
+
mtx_lock(&sndstat_lock);
if (!sndstat_isopen) {
mtx_unlock(&sndstat_lock);
- splx(s);
return EBADF;
}
- l = min(buf->uio_resid, sbuf_len(&sndstat_sbuf) - sndstat_bufptr);
- err = (l > 0)? uiomove(sbuf_data(&sndstat_sbuf) + sndstat_bufptr, l, buf) : 0;
- sndstat_bufptr += l;
+ l = min(buf->uio_resid, sbuf_len(&s->sbuf) - s->bufptr);
+ err = (l > 0)? uiomove(sbuf_data(&s->sbuf) + s->bufptr, l, buf) : 0;
+ s->bufptr += l;
mtx_unlock(&sndstat_lock);
- splx(s);
return err;
}
@@ -193,7 +182,6 @@
int
sndstat_register(device_t dev, char *str, sndstat_handler handler)
{
- intrmask_t s;
struct sndstat_entry *ent;
const char *d
please test pcm patch
Hello All,
Please test a pcm patch that releases the channel lock around
calls to uio move. This is a more complete patch than the previous
one as it also does the _read routine. I will ask the RE to commit
this if I hear a couple of "it works".
Pointed out by: Artur Poplawski
Explained by: Don Lewis
--Mat
--
sig machine broken
--- channel.c Sun Nov 9 04:17:22 2003
+++ /sys/dev/sound/pcm/channel.cWed Nov 26 13:50:20 2003
@@ -250,6 +250,8 @@
{
int ret, timeout, newsize, count, sz;
struct snd_dbuf *bs = c->bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
/*
@@ -291,7 +293,22 @@
sz = MIN(sz, buf->uio_resid);
KASSERT(sz > 0, ("confusion in chn_write"));
/* printf("sz: %d\n", sz); */
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 && togo> 0) {
+ p = sndbuf_getfreeptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_acquire(bs, NULL, t);
+ }
+ ret = 0;
+#endif
if (ret == 0 && !(c->flags & CHN_F_TRIGGERED))
chn_start(c, 0);
}
@@ -395,6 +412,8 @@
{
int ret, timeout, sz, count;
struct snd_dbuf *bs = c->bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
if (!(c->flags & CHN_F_TRIGGERED))
@@ -406,7 +425,22 @@
sz = MIN(buf->uio_resid, sndbuf_getready(bs));
if (sz > 0) {
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 && togo> 0) {
+ p = sndbuf_getreadyptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_dispose(bs, NULL, t);
+ }
+ ret = 0;
+#endif
} else {
if (c->flags & CHN_F_NBIO) {
ret = EWOULDBLOCK;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pcm(4) related panic
On Nov 25, Don Lewis wrote:
> On 25 Nov, Don Lewis wrote:
> > On 25 Nov, Artur Poplawski wrote:
> >> Artur Poplawski <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hello,
> >>>
> >>> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic
> >>> like this:
> >
> >>> Sleeping on "swread" with the following non-sleepable locks held:
> >>> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \
> >>> /usr/src/sys/dev/sound/pcm/dsp.c:146
> >
> > This enables the panic.
> >
> >>> panic: sleeping thread (pid 583) owns a non-sleepable lock
> >
> > Then the panic happens when another thread tries to grab the mutex.
> >
> >
> > The problem is that the pcm code attempts to hold a mutex across a call
> > to uiomove(), which can sleep if the userland buffer that it is trying
> > to access is paged out. Either the buffer has to be pre-wired before
> > calling getchns(), or the mutex has to be dropped around the call to
> > uiomove(). The amount of memory to be wired should be limited to
> > 'sz' as calculated by chn_read() and chn_write(), which complicates the
> > logic. Dropping the mutex probably has other issues.
>
> Following up to myself ...
>
> It might be safe to drop the mutex for the uiomove() call if the code
> set flags to enforce a limit of one reader and one writer at a time to
> keep the code from being re-entered. The buffer pointer manipulations
> in sndbuf_dispose() and sndbuf_acquire() would probably still have to be
> protected by the mutex. If this can be made to work, it would probably
> be preferable to wiring the buffer. It would have a lot less CPU
> overhead, and would work better with large buffers, which could still be
> allowed to page normally.
Don,
I never would have suspected that uio might sleep and panic,
thanks for the clue.
Artur,
Could you try the attached patch.
Thanks,
--Mat
--
Any idiot can face a crisis; it is this day-to-day living
that wears you out.
- Chekhov
--- channel.c Sun Nov 9 04:17:22 2003
+++ /sys/dev/sound/pcm/channel.cWed Nov 26 02:21:14 2003
@@ -250,6 +250,8 @@
{
int ret, timeout, newsize, count, sz;
struct snd_dbuf *bs = c->bufsoft;
+ void *off;
+ int t, x,togo,p;
CHN_LOCKASSERT(c);
/*
@@ -291,7 +293,22 @@
sz = MIN(sz, buf->uio_resid);
KASSERT(sz > 0, ("confusion in chn_write"));
/* printf("sz: %d\n", sz); */
+#if 0
ret = sndbuf_uiomove(bs, buf, sz);
+#else
+ togo = sz;
+ while (ret == 0 && togo> 0) {
+ p = sndbuf_getfreeptr(bs);
+ t = MIN(togo, sndbuf_getsize(bs) - p);
+ off = sndbuf_getbufofs(bs, p);
+ CHN_UNLOCK(c);
+ ret = uiomove(off, t, buf);
+ CHN_LOCK(c);
+ togo -= t;
+ x = sndbuf_acquire(bs, NULL, t);
+ }
+ ret = 0;
+#endif
if (ret == 0 && !(c->flags & CHN_F_TRIGGERED))
chn_start(c, 0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kern/59233: patch to soundcard.h to include an ioctl and a constant for midi
Hello All, I'm sorry to be a pain, but I think it's important this PR be commited before any branch. http://www.freebsd.org/cgi/query-pr.cgi?pr=59233 It's vital to build current midi software and it has been in other OSes for a while. Thanks, --Mat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sound patch for pop & crackles
Hello All,
Could people experiencing pops and crackles try the attached
patch and set hw.snd.fragps=128. This patch also fixes select on
vchans.
more details in
http://www.freebsd.org/cgi/query-pr.cgi?pr=59208
Thanks,
--Mat
--
I don't even know what street Canada is on.
- Al Capone
--- channel.c.old Wed Nov 12 02:42:43 2003
+++ channel.c Wed Nov 12 03:59:31 2003
@@ -41,6 +41,10 @@
#define DEB(x) x
*/
+static int chn_fragsps = 0;
+SYSCTL_INT(_hw_snd, OID_AUTO, fragsps, CTLFLAG_RW,
+ &chn_fragsps, 1, "max fragments per second, 0 to disable");
+
static int chn_targetirqrate = 32;
TUNABLE_INT("hw.snd.targetirqrate", &chn_targetirqrate);
@@ -59,7 +63,7 @@
return err;
}
SYSCTL_PROC(_hw_snd, OID_AUTO, targetirqrate, CTLTYPE_INT | CTLFLAG_RW,
- 0, sizeof(int), sysctl_hw_snd_targetirqrate, "I", "");
+ 0, sizeof(int), sysctl_hw_snd_targetirqrate, "I", "default fragment targets
this IRQ rate");
static int report_soft_formats = 1;
SYSCTL_INT(_hw_snd, OID_AUTO, report_soft_formats, CTLFLAG_RW,
&report_soft_formats, 1, "report software-emulated formats");
@@ -113,10 +117,17 @@
chn_wakeup(struct pcm_channel *c)
{
struct snd_dbuf *bs = c->bufsoft;
+struct pcmchan_children *pce;
- CHN_LOCKASSERT(c);
- if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c))
- selwakeup(sndbuf_getsel(bs));
+// CHN_LOCKASSERT(c);
+ if (SLIST_EMPTY(&c->children)) {
+ if (SEL_WAITING(sndbuf_getsel(bs)) && chn_polltrigger(c))
+ selwakeup(sndbuf_getsel(bs));
+ } else {
+ SLIST_FOREACH(pce, &c->children, link) {
+ chn_wakeup(pce->channel);
+ }
+ }
wakeup(bs);
}
@@ -931,7 +942,7 @@
{
struct snd_dbuf *b = c->bufhard;
struct snd_dbuf *bs = c->bufsoft;
- int bufsz, irqhz, tmp, ret;
+ int irqhz, tmp, ret;
CHN_LOCKASSERT(c);
if (!CANCHANGE(c) || (c->flags & CHN_F_MAPPED))
@@ -960,14 +971,23 @@
DEB(printf("%s: updating (%d, %d)\n", __func__, blkcnt,
blksz));
}
} else {
+ if ( chn_fragsps != 0 &&
+ sndbuf_getbps(bs) * sndbuf_getspd(bs) / blksz > chn_fragsps)
+ {
+ blksz = sndbuf_getbps(bs) * sndbuf_getspd(bs) / chn_fragsps;
+ tmp = 32;
+ while (tmp < blksz)
+ tmp <<= 1;
+ blksz = tmp;
+ if (blksz * blkcnt > CHN_2NDBUFMAXSIZE)
+ blkcnt = CHN_2NDBUFMAXSIZE / blksz;
+ }
ret = EINVAL;
if ((blksz < 16) || (blkcnt < 2) || (blkcnt * blksz >
CHN_2NDBUFMAXSIZE))
goto out;
ret = 0;
c->flags |= CHN_F_HAS_SIZE;
}
-
- bufsz = blkcnt * blksz;
ret = sndbuf_remalloc(bs, blkcnt, blksz);
if (ret)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sound LOR patches
On Oct 29, Kris Kennaway wrote: > On Tue, Oct 28, 2003 at 02:24:28PM -0500, Mathew Kanner wrote: > > Hello All, > > I tried to fix some LOR in -current and attached you will find > > some patches. > > I sent these to the -sound list but I didn't get a response. > > (Maybe I should mention that I'm also part of the -sound list). So > > now I don't know what's going in with sound and -current. > > Thanks very much for looking into this - it has been an outstanding > issue for too long. Hopefully some of the people who have reported > this can test your patches. "Dark Schneider" has tested all but the cmi patch. (He reported the LOR the other day). I've tested the CMI patch. --Mat -- Applicants must also have extensive knowledge of UNIX, although they should have sufficiently good programming taste to not consider this an achievement. - MIT AI Lab job ad in the /Boston Globe/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sound LOR patches
Hello All,
I tried to fix some LOR in -current and attached you will find
some patches.
I sent these to the -sound list but I didn't get a response.
(Maybe I should mention that I'm also part of the -sound list). So
now I don't know what's going in with sound and -current.
Anyway, the fixes are:
dsp_open: rearrange to only hold one lock at a time
dsp_close: ditto
mixer_hwvol_init: delete locking, the only consumer seems to
be the ess driver and it only call it a creation time, I
think the device will be stable across the sleepable malloc
in the dyn. sysctl allocation
cmi interrupt routine: Release locks while caller chn_intr,
We could either this or do what emu10k1 does which is have
no locks at in the interrupt handler.
Cheers,
--Mat
--
I don't even know what street Canada is on.
- Al Capone
--- dspold.cSun Sep 14 17:49:38 2003
+++ dsp.c Tue Oct 21 14:38:44 2003
@@ -174,6 +174,8 @@
intrmask_t s;
u_int32_t fmt;
int devtype;
+ int rdref;
+ int error;
s = spltty();
d = dsp_get_info(i_dev);
@@ -209,6 +211,8 @@
panic("impossible devtype %d", devtype);
}
+ rdref = 0;
+
/* lock snddev so nobody else can monkey with it */
pcm_lock(d);
@@ -251,67 +255,66 @@
return EBUSY;
}
/* got a channel, already locked for us */
- }
-
- if (flags & FWRITE) {
- /* open for write */
- wrch = pcm_chnalloc(d, PCMDIR_PLAY, td->td_proc->p_pid, -1);
- if (!wrch) {
- /* no channel available */
- if (flags & FREAD) {
- /* just opened a read channel, release it */
- pcm_chnrelease(rdch);
- }
- /* exit */
- pcm_unlock(d);
- splx(s);
- return EBUSY;
- }
- /* got a channel, already locked for us */
- }
-
- i_dev->si_drv1 = rdch;
- i_dev->si_drv2 = wrch;
-
- /* Bump refcounts, reset and unlock any channels that we just opened,
-* and then release device lock.
-*/
- if (flags & FREAD) {
if (chn_reset(rdch, fmt)) {
pcm_chnrelease(rdch);
i_dev->si_drv1 = NULL;
- if (wrch && (flags & FWRITE)) {
- pcm_chnrelease(wrch);
- i_dev->si_drv2 = NULL;
- }
pcm_unlock(d);
splx(s);
return ENODEV;
}
+
if (flags & O_NONBLOCK)
rdch->flags |= CHN_F_NBIO;
pcm_chnref(rdch, 1);
CHN_UNLOCK(rdch);
+ rdref = 1;
+ /*
+* Record channel created, ref'ed and unlocked
+*/
}
+
if (flags & FWRITE) {
- if (chn_reset(wrch, fmt)) {
- pcm_chnrelease(wrch);
- i_dev->si_drv2 = NULL;
- if (flags & FREAD) {
- CHN_LOCK(rdch);
- pcm_chnref(rdch, -1);
- pcm_chnrelease(rdch);
- i_dev->si_drv1 = NULL;
- }
- pcm_unlock(d);
- splx(s);
- return ENODEV;
+ /* open for write */
+ wrch = pcm_chnalloc(d, PCMDIR_PLAY, td->td_proc->p_pid, -1);
+ error = 0;
+
+ if (!wrch)
+ error = EBUSY; /* XXX Right return code? */
+ else if (chn_reset(wrch, fmt))
+ error = ENODEV;
+
+ if (error != 0) {
+ if (wrch) {
+ /*
+* Free play channel
+*/
+ pcm_chnrelease(wrch);
+ i_dev->si_drv2 = NULL;
}
- if (flags & O_NONBLOCK)
- wrch->flags |= CHN_F_NBIO;
- pcm_chnref(wrch, 1);
- CHN_UNLOCK(wrch);
+ if (rdref) {
+ /*
+* Lock, deref and release previously created record channel
+*/
+ CHN_LOCK(rdch);
+ pcm_chnref(rdch, -1);
+ pcm_chnrelease(rdch);
+ i_dev->si_drv1 = NULL;
+ }
+
+ pcm_unlock(d);
+ splx(s);
+ return error;
+ }
+
+ if (flags & O_NONBLOCK)
+ wrch->flags |= CHN_F_NBIO;
+
Re: pcm & exclusive sleep mutex with Oct19 CURRENT
Hello Paolo,
See below.
On Oct 20, Paolo Pisati wrote:
> from my dmesg:
> [snip]
> exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @
> /usr/src/sys/dev/sound/pcm/mixer.c:322
Could you try deleting the snd_mtxlock and snd_mtxunlock in
mixer_hwvol_init() in mixer.c? I think it's uneeded as the function
is only called in particular device instance creation and no-one
should be able touch it yet.
>
> acquiring duplicate lock of same type: "pcm channel"
> 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
> 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
> Stack backtrace:
Please try my "wild guess" patch that is attached. I tried to
re-arrange the routine to only hold one locked channel at a time. I
suppose another option would be flag the lock type as having
duplicates ok.
--Mat
--
If you optimize everything, you will always be unhappy.
- Don Knuth
--- dspold.cSun Sep 14 17:49:38 2003
+++ dsp.c Tue Oct 21 14:38:44 2003
@@ -174,6 +174,8 @@
intrmask_t s;
u_int32_t fmt;
int devtype;
+ int rdref;
+ int error;
s = spltty();
d = dsp_get_info(i_dev);
@@ -209,6 +211,8 @@
panic("impossible devtype %d", devtype);
}
+ rdref = 0;
+
/* lock snddev so nobody else can monkey with it */
pcm_lock(d);
@@ -251,67 +255,66 @@
return EBUSY;
}
/* got a channel, already locked for us */
- }
-
- if (flags & FWRITE) {
- /* open for write */
- wrch = pcm_chnalloc(d, PCMDIR_PLAY, td->td_proc->p_pid, -1);
- if (!wrch) {
- /* no channel available */
- if (flags & FREAD) {
- /* just opened a read channel, release it */
- pcm_chnrelease(rdch);
- }
- /* exit */
- pcm_unlock(d);
- splx(s);
- return EBUSY;
- }
- /* got a channel, already locked for us */
- }
-
- i_dev->si_drv1 = rdch;
- i_dev->si_drv2 = wrch;
-
- /* Bump refcounts, reset and unlock any channels that we just opened,
-* and then release device lock.
-*/
- if (flags & FREAD) {
if (chn_reset(rdch, fmt)) {
pcm_chnrelease(rdch);
i_dev->si_drv1 = NULL;
- if (wrch && (flags & FWRITE)) {
- pcm_chnrelease(wrch);
- i_dev->si_drv2 = NULL;
- }
pcm_unlock(d);
splx(s);
return ENODEV;
}
+
if (flags & O_NONBLOCK)
rdch->flags |= CHN_F_NBIO;
pcm_chnref(rdch, 1);
CHN_UNLOCK(rdch);
+ rdref = 1;
+ /*
+* Record channel created, ref'ed and unlocked
+*/
}
+
if (flags & FWRITE) {
- if (chn_reset(wrch, fmt)) {
- pcm_chnrelease(wrch);
- i_dev->si_drv2 = NULL;
- if (flags & FREAD) {
- CHN_LOCK(rdch);
- pcm_chnref(rdch, -1);
- pcm_chnrelease(rdch);
- i_dev->si_drv1 = NULL;
- }
- pcm_unlock(d);
- splx(s);
- return ENODEV;
+ /* open for write */
+ wrch = pcm_chnalloc(d, PCMDIR_PLAY, td->td_proc->p_pid, -1);
+ error = 0;
+
+ if (!wrch)
+ error = EBUSY; /* XXX Right return code? */
+ else if (chn_reset(wrch, fmt))
+ error = ENODEV;
+
+ if (error != 0) {
+ if (wrch) {
+ /*
+* Free play channel
+*/
+ pcm_chnrelease(wrch);
+ i_dev->si_drv2 = NULL;
}
- if (flags & O_NONBLOCK)
- wrch->flags |= CHN_F_NBIO;
- pcm_chnref(wrch, 1);
- CHN_UNLOCK(wrch);
+ if (rdref) {
+ /*
+* Lock, deref and release previously created record channel
+*/
+ CHN_LOCK(rdch);
+ pcm_chnref(rdch, -1);
+ pcm_chnrelease(rdch);
+ i_dev->si_drv1 = NULL;
+ }
+
+ pcm_unlock(d);
+ splx(s);
+ return error;
+ }
+
+ if (flags & O_NONBLOCK)
+ wrch->flags |=
Re: Specifying default alternate sound device?
On Aug 05, Adam wrote: > Is there any easy way to specify a default alternate sound device (eg, > /dev/dsp1). I have both onboard sound (/dev/dsp) and a SB Live card > (/dev/dsp1), but I don't use the onboard sound. It's really frustrating > to try to configure every single application (that uses sound) to use > /dev/dsp1 instead. > > Is there some safe/easy trick to set a general rule that all/most apps > will follow, so that they use /dev/dsp1 instead? With devfs, the default sound unit is tunable by a sysctl. tube# sysctl hw.snd.unit=0 ; ls -l dsp dsp0.0 dsp1.0 ; sysctl hw.snd.unit=1 ; ls -l dsp dsp0.0 dsp1.0 hw.snd.unit: 1 -> 0 crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp0.0 crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp1.0 hw.snd.unit: 0 -> 1 crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp0.0 crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp1.0 --Mat -- sig machine broken. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sound Blaster Live DD5.1
> [ Thomas and Emil talk about Dell OEM SB, Emil gives a pciconf ] Could somebody with Dell OEM card try this patch and report back? --Mat -- Brain: Pinky, are you pondering what I'm pondering? Pinky: I think so Brain, but if you replace the P with an O, my name would be Oinky, wouldn't it? --- emu10k1.c Sun Jun 8 13:56:01 2003 +++ /tmp/e Sun Jun 8 13:55:37 2003 @@ -1446,6 +1446,9 @@ s = "Creative EMU10K2"; break; */ + case 0x00061102: + s = "Dell EMU10K1"; + break; default: return ENXIO; } ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: midi problem, an isa device on a pci card
Hello,
I've recived no responses. Anyway, the following includes my
own solution to the question, lots of trial and error. I've found that
isahints was the closest exsting code to what I wanted.
As always, I would love to hear any comments.
> How do I create isa devices from a pci device. Do I search up the
> soundcard tree for the pci bus then search down for the isa bus, then
> create_child(..."mpushim")?
In pci device_attach:
isa=devclass_find("isa");
if( !isa ) {
device_printf(sc->dev,"cmi midi error no devclass for isa\n");
goto err;
}
if (devclass_get_devices(isa, &isalistp, &isacountp) != 0 ) {
device_printf(sc->dev,"cmi midi error fetching isa devices\n");
goto err;
}
if ( isacountp < 1 ) {
device_printf(sc->dev,"cmi midi no isa busses found\n");
goto err;
}
/*
* Be stupid and just pick the first isa bus
*/
sc->isadev = isalistp[0];
mpuisa=devclass_find("mpuisa");
if( !mpuisa ) {
device_printf(sc->dev,"cmi: midi driver not found\n");
goto err;
}
i = devclass_find_free_unit(mpuisa,0);
sc->mpudev = BUS_ADD_CHILD(sc->isadev, 1, "mpuisa", i);
[Needs to be done with BUS_ADD_CHILD, I tried with others, m' yo
they just don't work]
> How do I tell the shim before the probe/attach what io region to look
> at, do I fiddle with ivars (or some internal structure), do I mess with hints
> via kenv(9) [Is there a kenv(9)? ]
[ Say, p->port=0x300, then following would set it to 0x300-0x302
and the same IRQ as the pci device ]
bus_set_resource(sc->mpudev, SYS_RES_IOPORT, 0, p->port, 2);
bus_set_resource(sc->mpudev, SYS_RES_IRQ, 0, rman_get_start(sc->irq), 1);
if( device_probe_and_attach(sc->mpudev) == 0 ) {
device_printf(sc->dev,"added %s/%s\n",
device_get_nameunit(sc->isadev),
device_get_nameunit(sc->mpudev) );
return ;
}
Cheers,
--Mat
--
Brain: Are you pondering what I'm pondering?
Pinky: I think so Brain, but the Rockettes, it's mostly girls, isn't it?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
midi problem, an isa device on a pci card
Hello,
I've been fiddling with pci drivers in freebsd for a couple of
months and up to now everything has ok, I did a midi driver for es137x
which was relatively easy because the io was done on the pci bus. I
was very pleased that there were enough resources for a newbie like me
to dive into kernel hacking.
Now I want to do one for the cmi card, but it seems to offer
the midi device on the isa bus, as does a bunch of cards. I'm sure
they did this to confuse me.
Linux seems to be happy just inb,outb in their pci driver,
which seems uncool to me. Also since I can program the mpu to appear
to different locations I think the ISA bus driver can help determine
the best one to use...
Theory of Reality (mostly hand waving, as I've done no code yet)
Drivers:
cmi(pci), my pci sound, it's on board btw.
mpushim(isa), the mpu401 from the tree but hacked to receive
from the pci soundcard driver
How I think should work:
probe cmi,
attach cmi,
do {
enable mpu401 at port region,
probe attach mpushim
while ( ! mpushim attached )
done
Big question mark:
How do I create isa devices from a pci device. Do I search up the
soundcard tree for the pci bus then search down for the isa bus, then
create_child(..."mpushim")?
How do I tell the shim before the probe/attach what io region to look
at, do I fiddle with ivars (or some internal structure), do I mess with hints
via kenv(9) [Is there a kenv(9)? ]
I think that these questions equally apply to joysticks.
Thanks,
--Mat
--
Brain: Are you pondering what I'm pondering?
Pinky: I think so, Brain, but if the plural of mouse is mice, wouldn't
the plural of spouse be spice?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MIDI on SB Live! ?
On Mar 22, Michael Nottebrock wrote: > On Friday 21 March 2003 21:01, [EMAIL PROTECTED] wrote: > > just out of curiosity: Is someone working in MIDI support for Creative > > EMU10K1 based sound cards (aka Soundblaster Live!) ? > On and off, as far as I can tell. If you want MIDI right now, take a look at > what 4Front Technologies offers in their commercial OSS package. Hello Micheal and all, (this is reply targeted at the thread) In not sure about 4front compatability with -current. ALSA would require a complete rewrite to work for multiple platforms because they are intimate with the linux pci interface. IMHO, it would require a fork of their project. MIDI in FreeBSD is highly hackable. It took me only a couple of days to get midi working for an es173x, a made a small web page a few months ago, it was for 5.0-dp2 but would probably work with 5.0-R. As it is, midi can be a kld and all that is required for a particular card is basic IO. The emu10k should be easier than most because we already have code for a generic mpu401. Here are some web links, http://www.cnd.mcgill.ca/~mat/es137xmidi.html (my small es137x midi page, mostly derived from other sources) Nice references for midi hacking: from NetBSD (it's .se.netbsd because .netbsd seems to be down) http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/midi.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/midisyn.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/sequencer.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/pci/esa.c http://cvsweb.se.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/dev/pci/emuxki.c (oops, no midi for emu on netbsd) from ALSA: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-kernel/drivers/mpu401/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-kernel/pci/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa/alsa-kernel/pci/emu10k1/ After all of this, the reality is, very few people care about midi for freebsd and it has been neglected for along time. We're lucky that the work done long ago still works. --Mat -- Brain: Pinky, are you pondering what I'm pondering? Pinky: I think so Brain, but pants with horizontal stripes make me look chubby. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hw.acpi.disable_on_poweroff
On Jan 27, Scott Sipe wrote: > > This defaulted to 1 ony my Current--is there a reason for this? I like > being able to press the power putton and have it shutdown properly, or have > shutdown -p power down. Hello Scott, When it's 0, it's prevents some rogue machines from mysteriously turning on a few minutes after power off, like my bp6 motherboard. --Mat -- Brain: Are you pondering what I'm pondering? Pinky: Wuh, I think so, Brain, but wouldn't anything lose its flavor on the bedpost overnight? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DP2 won't stay powered off
On Dec 05, Nate Lawson wrote: > On Thu, 5 Dec 2002, Mathew Kanner wrote: > > I've noticed some odd behavior when I installed DP2 on my > > machine last night. When I "shutdown -p now", the machine will turn > > itself back-on in about twenty minutes. This would be nice feature if > > I had asked for it. > > Can everyone with the auto power on problem report the output of "sysctl > hw.acpi"? hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 0 hw.acpi.cpu.max_speed: 2 hw.acpi.cpu.current_speed: 2 hw.acpi.cpu.performance_speed: 2 hw.acpi.cpu.economy_speed: 1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3247 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3482 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3482 hw.acpi.thermal.tz0._ACx: 3482 -1 -1 -1 -1 -1 -1 -1 -1 -1 --Mat -- Mr. T (On Late Night with Conan O'Brian): "Fools will come to my house to ask me not to pity them. But I won't be home, and it will be raining, so I will continue to pity them!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DP2 won't stay powered off
Hello, I've noticed some odd behavior when I installed DP2 on my machine last night. When I "shutdown -p now", the machine will turn itself back-on in about twenty minutes. This would be nice feature if I had asked for it. I've never seen this before with -current (which I haven't visited in about six months) or -stable with apm. The machine is an abit bp6, dual celeron. I've never updated the bios, and I assume this is an acpi problem. -current isn't booted at the moment but more specific information can be provided. Thanks, --Mat -- Brain: Moo. We are a cow. Take us to China. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rc.diskless -> /sbin/mdfs
Hello -current, There seems to be some interest in discussing changes to rc.diskless and I tried to come with a set of variables and shell code for rc.conf and rc.diskless that would allow for tuning the fs (# of inodes, softupdates, etc) as well as filesystems other than ufs. It seems complex enough to warrant being factored out of rc.diskless and into it's own utility. (I can't really think of a reason to want msdos, ext2fs or ifs on temporary storage but I think the option should be available anyway.) I propose having /etc/mdfs.conf and /sbin/mdfs, although I'm not attached to these names. Mdfs.conf is similar in spirit to /etc/vntab but would contain filesystem options as well. Mdconfig doesn't currently have the ability to read configuration files, maybe that's the real solution. Mdfs would read mdfs.conf (or specified file) and would configure the md device via mdconfig, optionally disklabel, run the appropriate 'make fs' and 'tune fs' commands, and optionally mount the disk via mount. [An alternative to this scheme could be to have a mount_md command but I wouldn't know how to get enough information to mount then to mount_md to cover the gammet of options available.] But I'm stuck on two points I would like to solicit ideas: - How should the config file should look. I like the one-line per config entry, a la: md /var swap ufs size="10m" reserve fsopt="-c 90 -m 0" \ tuneopt="-n enable" md /fast malloc ifs size="100m" md /library file="/opt/chemlib.iso" iso9660 /dev/md10 /tmp ufs size="10m" But it might get ugly when escaping the argument strings. - How aware should the utility be of filesystems? Should it handle non ufs filesystems in a arbitrary manner, perhaps like the following config line: md /tmp swap unknown size="100m" no_disklabel newfs="newfs_msdos" \ mount_type="msdos" Or should it know internally of msdos, The minimum is ufs, of course. Anyway, my pain threshold is pretty high so I would prefer to hear that this is all bad than not to hear anything at all :) Thanks, --Mat -- Mathew Kanner <[EMAIL PROTECTED]> Sys Admin at large Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.diskless{1,2} files
On Mar 30, Falco Krepel wrote:
> I have implemented good ideas from Mike Smith in my
> rc.diskless{1,2} files and make some other changes:
Hi,
I don't have access to hardware to test diskless but have a
few suggestions from looking at proposal.
BOOTP probably isn't how most people are going to do it,
instead they will be using PXE, perhaps we should retire the reference
to BOOTP in the following.
> #
> # /etc/rc.diskless1 - general BOOTP startup
> #
> # BOOTP has mounted / for us. Assume a read-only mount. We must then
> # - figure out our IP by querying the interface
> # - fill /conf/etc (writable) with files from /etc, and then update
> # per-machine files from /conf/*/ where * is the IP of the host,
> # the IP of the subnet, "default", or nothing.
> # - mount /conf/etc over /etc so we can see the new files.
> #
> # WARNING: i thing you should not change /etc/rc or strange things could
> md_device=`mdconfig -a -t malloc -s $1`
> chkerr $? "configuring md device"
> disklabel -rw $md_device auto
> chkerr $? "labelling md device"
> md_filesystem=/dev/$md_device"c"
> newfs $md_filesystem 2>&1 >/dev/null
> chkerr $? "making md device filesystem"
> mount $md_filesystem $2
Barring a change in newfs or mount, it would be nice if it
could tunefs to enable softupdates.
> bootp_ifc=""
> bootp_ipa=""
> bootp_ipbca=""
> iflist=`ifconfig -l`
> for i in ${iflist} ; do
> set `ifconfig ${i}`
> while [ $# -ge 1 ] ; do
> if [ "${bootp_ifc}" = "" -a "$1" = "inet" ] ; then
> bootp_ifc=${i} ; bootp_ipa=${2} ; shift
> fi
> if [ "${bootp_ipbca}" = "" -a "$1" = "broadcast" ] ; then
> bootp_ipbca=$2; shift
> fi
> shift
> done
> if [ "${bootp_ifc}" != "" ] ; then
> break
> fi
> done
> echo "Interface ${bootp_ifc} IP-Address ${bootp_ipa} Broadcast ${bootp_ipbca}"
IIRC, PXE sets a kernel env. with this info. Maybe we should
try to grab that first and then fall back to the above.
> [...]
My final thought is that I remember having to stick a
chkprintcap -d somewhere to make it a happy workstation.
--Mat
--
Mathew Kanner <[EMAIL PROTECTED]> Sys Admin at large
Obtuse quote: He [not me] understands: "This field of perception
is void of perception of man." -- The Quintessence of Buddhism
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PXE build?
On Nov 14, Jeff Roberson wrote: > Does anyone know of any current issues with PXE? I've searched the mailing > lists and I don't see any mention of a problem similar to mine. > > I'm running FreeBSD-CURRENT from 2000 09 15 on a server. The client has an > Intel 21143 based ethernet card that claims it has PXE 2.0 (Build 74) > support. I've setup bootp/tftp on the server which the client successfully > uses to pull down the 'pxeboot' file. After the client retrieves pxeboot it > just hangs. There is no further output from the machine. > > Does anyone know which particular build of PXE 2.0 works with pxeboot? Or > is this even a problem with my firmware? Hello Jeff, You didn't specify if you set-up NFS for the loader to fetch it's configuration and the kernel and such. Assuming you have an otherwise working PXE environment: I've had problems with Intel card at work. I'm at home now and don't remember off-hand what specific model of card or the flash version. Depending on what motherboard was used, I would see crashes and hangs in the loader when configured for tftp (with some), nfs (with others). However, recently someone on -questions referenced a flash upgrade available and I found it on the Intel web site. It fixed all my problems. --Mat > > Thanks, > Jeff -- Mathew Kanner <[EMAIL PROTECTED]> SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ntpdate bug(?)
[Following up] I'm embarassed to say that I missed the following sentence in the ntpdate man page. -b [...]This option should be used when called from the a startup file at boot time. This should have rung a bell for me. Thanks to the guy who responded. --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ntpdate bug(?)
Hi, I posted something similar on -questions but had no reponse. Could someone tell me if this is a bug? Ntpdate won't set the date when the current date is ahead but will set the date when it's behind. I've noticed this on 4.1 and -current from this past weekend. (I'm not talking about the 'send: Socket...' problem). bash-2.03# date Thu Aug 3 10:15:32 EDT 2000 bash-2.03# date 0008041015 date: send: Socket is not connected Fri Aug 4 10:15:00 EDT 2000 bash-2.03# Aug 4 10:15:00 magnet date: date set by root bash-2.03# ntpdate gps.freebsd.dk 4 Aug 10:15:16 ntpdate[404]: adjust time server 212.242.40.181 offset -86356.115919 sec bash-2.03# date Fri Aug 4 10:15:18 EDT 2000< This is what I mean bash-2.03# date 0008011015 date: send: Socket is not connected Tue Aug 1 10:15:00 EDT 2000 bash-2.03# ntpdate gps.freebsd.dk 3 Aug 10:16:25 ntpdate[407]: step time server 212.242.40.181 offset 172878.565883 sec bash-2.03# date Thu Aug 3 10:16:26 EDT 2000 bash-2.03# --Mat -- Mathew Kanner <[EMAIL PROTECTED]> Systems Programmer, SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overwhelming messages from /sys/netinet/if_ether.c
On Apr 07, Donn Miller wrote: > Since I started using a cable modem and dhclient, my system has been > literally overwhelmed with messages like: > > /kernel: arp: xx:xx:xx:xx:xx:xx is using my IP address 0.0.0.0! > I haven't tried this but how about changing the /sbin/dhclient-script to not use 0.0.0.0 as the address that wakes up the interface. --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vinum breakage
On Apr 05, Matthew Dillon wrote:
> (needless to say, the patch I posted is relative to FreeBSD-4.x, not 5)
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
Here's what I got, don't put too much salt into it, somehow,
the disks are a mix of ata66 and ata33. It also happened the exact
moment I did a control-t to get the status of a tar. I'll try again
with all ata/33 or all ata/66 later tonight.
--Mat
Script started on Wed Apr 5 12:33:13 2000
bash-2.03# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) core-file(kgdb) [Kexec-file /kernel
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...cdone.
(kgdb) core-file /usr/tmp/vmcore.6
IdlePTD 4157440
initial pcb at 364ec0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc274cf3c
stack pointer = 0x10:0xc032198c
frame pointer = 0x10:0xc03219a8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = bio
trap number = 12
panic: page fault
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x30
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc025e120
stack pointer = 0x10:0xc03217c4
frame pointer = 0x10:0xc03217c8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = bio
trap number = 12
panic: page fault
Uptime: 17m47s
dumping to dev #ad/0x20001, offset 3047552
dump ata0: resetting devices .. done
511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495
494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478
477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461
460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444
443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427
426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410
409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393
392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376
375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359
358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342
341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325
324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308
307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291
290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274
273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257
256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223
222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206
205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189
188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155
154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138
137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121
120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104
103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59
58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13
12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
#1 0xc017fa18 in poweroff_wait (junk=0xc0317dcf, howto=0)
at ../../kern/kern_shutdown.c:554
#2 0xc02ba969 in trap_fatal (frame=0xc0321784, eva=48)
at ../../i386/i386/trap.c:924
#3 0xc02ba641 in trap_pfault (frame=0xc0321784, usermode=0, eva=48)
at ../../i386/i386/trap.c:817
#4 0xc02ba237 in trap (frame={tf_fs = -1070465008, tf_es = -1072234480,
tf_ds = -1028587504, tf_edi = 0, tf_esi = 0, tf_ebp = -1070458936,
Re: ata + vinum problems
On Mar 23, Matthew Dillon wrote: > Oh, addendum... I didn't see this email regarding an actual panic. > > There are two problems here, one of which (the nbufkv lockup) should > be solved by my previous email. > > The second problem is this panic you are reporting, and I have no idea > what is causing it so this issue remains open. It could be softupdates, > it could be vinum, or it could be the ATA driver. > > What you need to do to help solve the panic is to gdb a debug version > of the kernel image rather then the non debug version so the stack > backtrace contains source line numbers and such. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> Included is a better backtrace. This does not include the patch that you suggested, I will do that tommorow. Thanks, --Mat Script started on Thu Mar 23 17:07:47 2000 bash-2.03# gdk b -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) exec-file v kernel.3 (kgdb) c symbol-file /usr/sr/ c/sys/compile/KAZE/kernel.debug Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done. (kgdb) core-file vmcore.3 IdlePTD 4157440 initial pcb at 364ec0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8:0xc0175f96 stack pointer = 0x10:0xc0321948 frame pointer = 0x10:0xc0321948 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025e120 stack pointer = 0x10:0xc0321780 frame pointer = 0x10:0xc0321784 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Uptime: 5m27s dumping to dev #ad/0x20001, offset 3047552 dump ata0: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:304 304 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=260) at ../../kern/kern
Re: ata + vinum problems
On Mar 15, Mathew Kanner wrote: > On Mar 15, Greg Lehey wrote: > > attention yet, but I do see that your problem relates to soft > > updates. It's not clear that the soft updates themselves are a cause > > of the problem, or just a facilitator, but it would be interesting to > I did try it couple of days back with and without softupdates. > Softupdates only made the problems appear more quickly but > I've lost track of all the combinations that's I've tried so I > should try one more time without. After some more time spent with the system. It turns out it is softupdates. I can complete the script (which copies /usr/ports to a newfs'ed system) without softupdates but with, it will stall and then crash. An interesting note, with softupdates, during a stall I did a sysctl vfs.hidirtbuffers=500 and it completed, howver, if I do this before running the script, it crashes as well (but doesn't take nearly as long to do so). Included is a traceback of when it crashed witht he hibuffers at 500. --Mat Script started on Thu Mar 23 15:23:03 2000 bash-2.03# gdb -k GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd". (kgdb) core[Kexec-file kernel2. kernel2.: No such file or directory. (kgdb) ecxxec-file kernel.2 (kgdb) coresuymbol-file /usr/src/sys/compile/KZAZE/kernel.debug Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done. (kgdb) core-file vmcore.2 IdlePTD 4165632 initial pcb at 364ea0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc026745a stack pointer = 0x10:0xc03218e4 frame pointer = 0x10:0xc03218f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025e10c stack pointer = 0x10:0xc032171c frame pointer = 0x10:0xc0321720 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Uptime: 6m53s dumping to dev #ad/0x20001, offset 3047552 dump ata0: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 3
Re: ata + vinum problems
On Mar 15, Greg Lehey wrote: > > Replying to myself. By now this is probably the wrong list. > > I'm not sure what to do anymore. I've tried to set the bios > > settings back to what I've had when it worked it it doesn't seem to > > want to go. I've set the drives for ata/66 and ata/33. I've moved > > IRQ's around and even tried forcing them. Here are sets of dmesg and > > backtraces. This also happens with a kernel and modules compiled on > > sunday. > > The part that really bothers me is that I have a nearly > > identical machine, except for an extra drive in it that originally had > > the same problems but when I disabled the extra periphs, the problem > > went away. > > I'm a bit behind in my mail, and I don't have time to give this proper > attention yet, but I do see that your problem relates to soft > updates. It's not clear that the soft updates themselves are a cause > of the problem, or just a facilitator, but it would be interesting to > see what happens if you turn them off. Note also that there are some > bogons in your config, to judge by the vinum startup messages. I'll > analyse this in a day or two when I (hopefully) have more time. The bogons me were messing me around with Vinum before I figured out that the crash had messed up one of the disklabels. This occurs occasionally after a crash. I did try it couple of days back with and without softupdates. Softupdates only made the problems appear more quickly but I've lost track of all the combinations that's I've tried so I should try one more time without. Thanks, --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata + vinum problems
On Mar 15, Mathew Kanner wrote:
> On Mar 15, Soren Schmidt wrote:
> > Btw are you running the latest 4.0 or -current code ? there was
> > a time when we had problems with the HPT and Promise controllers ?
>
> The kernel in question was cvsup'ed right at the change. I'm
> going to try 4.0 today.
Replying to myself. By now this is probably the wrong list.
I'm not sure what to do anymore. I've tried to set the bios
settings back to what I've had when it worked it it doesn't seem to
want to go. I've set the drives for ata/66 and ata/33. I've moved
IRQ's around and even tried forcing them. Here are sets of dmesg and
backtraces. This also happens with a kernel and modules compiled on
sunday.
The part that really bothers me is that I have a nearly
identical machine, except for an extra drive in it that originally had
the same problems but when I disabled the extra periphs, the problem
went away.
Any suggestions?
--Mat
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #5: Tue Mar 14 22:07:49 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KAZE
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (551.25-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x387f9ff
real memory = 536870912 (524288K bytes)
avail memory = 516157440 (504060K bytes)
Preloaded elf kernel "kernel" at 0xc03e3000.
Pentium Pro MTRR support enabled
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
pci1: at 0.0
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: at 7.2
chip1: port 0x5000-0x500f at device 7.3 on
pci0
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xa400-0xa47f mem 0xe606-0xe606007f
irq 7 at device 11.0 on pci0
xl0: Ethernet address: 00:50:da:d6:6a:d0
miibus0: on xl0
xlphy0: <3Com internal media interface> on miibus0
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: supplying EUI64: 00:50:da:ff:fe:d6:6a:d0
atapci1: port
0xb800-0xb83f,0xb400-0xb403,0xb000-0xb007,0xac00-0xac03,0xa800-0xa807 mem
0xe600-0xe601 irq 5 at device 13.0 on pci0
ata2: at 0xa800 on atapci1
ata3: at 0xb000 on atapci1
atapci2: port
0xcc00-0xcc3f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 mem
0xe604-0xe605 irq 10 at device 15.0 on pci0
ata4: at 0xbc00 on atapci2
ata5: at 0xc400 on atapci2
atapci3: port
0xe000-0xe03f,0xdc00-0xdc03,0xd800-0xd807,0xd400-0xd403,0xd000-0xd007 mem
0xe602-0xe603 irq 11 at device 17.0 on pci0
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
kbd0 at atkbd0
psm0: irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250
sio1: configured irq 3 not in bitmap of probed irqs 0
ppc0: parallel port not found.
ad0: 26063MB [52953/16/63] at ata0-master using UDMA33
ad4: 26063MB [52953/16/63] at ata2-master using UDMA66
ad6: 26063MB [52953/16/63] at ata3-master using UDMA66
ad8: 26063MB [52953/16/63] at ata4-master using UDMA66
ad10: 26063MB [52953/16/63] at ata5-master using UDMA66
acd0: CD-RW at ata1-master using PIO4
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted
vinum: loaded
vinum: reading configuration from /dev/ad6s1e
vinum: updating configuration from /dev/ad8s1e
vinum: updating configuration from /dev/ad10s1e
vinum: updating configuration from /dev/ad4s1e
xl0: starting DAD for fe80:0001::0250:daff:fed6:6ad0
xl0: DAD complete for fe80:0001::0250:daff:fed6:6ad0 - no duplicates found
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:304
#1 0xc017f12c in poweroff_wait (junk=0xc03167af, howto=0)
at ../../kern/kern_shutdown.c:554
#2 0xc02ba019 in trap_fatal (frame=0xc031fe64, eva=48)
at ../../i386/i386/trap.c:924
#3 0xc02b9cf1 in trap_pfault (frame=0xc031fe64, usermode=0, eva=48)
at ../../i386/i386/trap.c:817
#4 0xc02b98e7 in trap (frame={tf_fs = -1070530544, tf_es = -1072234480,
tf_ds = -1028915184, tf_edi = 0, tf_esi = 0, tf_ebp = -1070465368,
tf_isp = -1070465392, tf_ebx = -1070364388, tf_edx = 1074316384,
tf_ecx = -1030807537, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071262112, tf_cs = 8, tf_eflags = 66054, tf_esp = -856772416,
tf_ss = -107
Re: ata + vinum problems
On Mar 15, Soren Schmidt wrote: > It seems Mathew Kanner wrote: > > disks on Promise controllers. I believe that the problems lies with > > multiple cards on the same interupt but what do I know -- execpt that > > the problem goes away when I disable most devices in the BIOS. > > The motherboard is a abit BE6-II, I've enabled most BIOS > > periphs such as serial ports, printer ports, usb, vga ints but not APM. > > Hmm, I've seen references on the net to the BE6 having trouble with > ATA PCI controllers in one of the slots if the internal controller > is enabled, I dont know which slot that is unfortunately, so moving > things around is my best guess. I did get hit by that, in this case it's the 5th pci slot. When there a controller in there, the system just locks completly. > Btw are you running the latest 4.0 or -current code ? there was > a time when we had problems with the HPT and Promise controllers ? The kernel in question was cvsup'ed right at the change. I'm going to try 4.0 today. --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata + vinum problems
Hi All,
I wanted to document my difficuties with Vinum and multiple
disks on Promise controllers. I believe that the problems lies with
multiple cards on the same interupt but what do I know -- execpt that
the problem goes away when I disable most devices in the BIOS.
The motherboard is a abit BE6-II, I've enabled most BIOS
periphs such as serial ports, printer ports, usb, vga ints but not APM.
I've included the script that causes the crash, a back-trace
and dmesg output right before the crash and the kernel config. The
raid devices where made via the vinum simplified commands (which are
*very nice*).
It should be noted that I had to control the 'tar' part of the
script because it was stuck in a "nbufkv" and disk activity ceases.
The crash happened upto 10 seconds after I get a shell prompt back.
The "nbufkv" was the sure sign that something had gone wrong in my
previous 'uncontrolled' tests.
--Mat
#!/bin/sh -x
BLOCK_SIZE=`expr 32 \* 1024`
FRAG_SIZE=`expr 8 \* 1024`
ISIZE=`expr 6 \* ${FRAG_SIZE}`
#CYL=635
CYL=200
FAKE=""
DEV="/dev/vinum/raid5"
MOUNT="/mnt1"
newfs ${FAKE} -v -b ${BLOCK_SIZE} -f ${FRAG_SIZE} -i ${ISIZE} -c ${CYL} ${DEV}
tunefs -n enable ${DEV}
mount ${DEV} ${MOUNT}
tar cf - -C /usr/ ports | tar xf - -C ${MOUNT}
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #4: Mon Mar 13 17:54:22 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KAZE
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (551.25-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x387f9ff
real memory = 536870912 (524288K bytes)
avail memory = 516128768 (504032K bytes)
Preloaded elf kernel "kernel" at 0xc03e9000.
Pentium Pro MTRR support enabled
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
pci1: at 0.0 irq 10
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: at 7.2 irq 9
chip1: port 0x5000-0x500f at device 7.3 on
pci0
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0x9400-0x947f mem 0xe706-0xe706007f
irq 9 at device 11.0 on pci0
xl0: Ethernet address: 00:50:da:d6:6a:d0
miibus0: on xl0
xlphy0: <3Com internal media interface> on miibus0
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: supplying EUI64: 00:50:da:ff:fe:d6:6a:d0
atapci1: port
0xa800-0xa83f,0xa400-0xa403,0xa000-0xa007,0x9c00-0x9c03,0x9800-0x9807 mem
0xe704-0xe705 irq 11 at device 13.0 on pci0
ata2: at 0x9800 on atapci1
ata3: at 0xa000 on atapci1
atapci2: port
0xbc00-0xbc3f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 mem
0xe702-0xe703 irq 5 at device 15.0 on pci0
ata4: at 0xac00 on atapci2
ata5: at 0xb400 on atapci2
atapci3: port
0xd000-0xd03f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 mem
0xe700-0xe701 irq 10 at device 17.0 on pci0
atapci4: port
0xdc00-0xdcff,0xd800-0xd803,0xd400-0xd407 irq 11 at device 19.0 on pci0
atapci5: port
0xe800-0xe8ff,0xe400-0xe403,0xe000-0xe007 irq 11 at device 19.1 on pci0
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
kbd0 at atkbd0
psm0: irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, 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: cannot reserve I/O port range
ad0: 26063MB [52953/16/63] at ata0-master using UDMA33
ad4: 26063MB [52953/16/63] at ata2-master using UDMA66
ad6: 26063MB [52953/16/63] at ata3-master using UDMA66
ad8: 26063MB [52953/16/63] at ata4-master using UDMA66
ad10: 26063MB [52953/16/63] at ata5-master using UDMA66
acd0: CD-RW at ata1-master using PIO4
Mounting root from ufs:/dev/ad0s1a
vinum: loaded
vinum: reading configuration from /dev/ad10s1e
vinum: updating configuration from /dev/ad8s1e
vinum: updating configuration from /dev/ad4s1e
vinum: updating configuration from /dev/ad6s1e
xl0: starting DAD for fe80:0001::0250:daff:fed6:6ad0
xl0: DAD complete for fe80:0001::0250:daff:fed6:6ad0 - no duplicates found
#0 0xc017f008 in boot ()
#1 0xc017f38c in poweroff_wait ()
#2 0xc02ba2a9 in trap_fatal ()
#3 0xc02b9f81 in trap_pfault ()
#4 0xc02b9b77 in trap ()
#5 0xc025d8b4 in acquire_lock ()
#6 0xc026081a in initiate_write_filepage ()
#7 0xc02606e7 in softdep_disk_io_initiation ()
#8 0xc01b45b7 in spec_strategy ()
#9 0xc01b40ed in spec_vnoperate ()
#10 0xc026c4c9 in ufs_vnoperatesp
RC3: burncd/ata problems
I've got a new machine that I was testing FreeBSD out on. I had large problems with promise ata controller and fujistsu drives, a red-herring on the promise site was that they can't run ata66. Turns out that the last pci slot on the a-bit BE6-II doesn't work regularly when the on-board udma66 controller is enabled. Problem #1, the CD-R on this system doesn't recongize on the on board udma66 port but does on the promise PCI card. However, it shows up in the bios scan both ways. Problem #2, burncd failed with some (not verbatim) 'wrote -1 of n'. I'm remote from the machine now so I can't reproduce the error output that burncd did. The dmesg that follows has the some of the errors. I'll provide more info if needed. --Mat Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-2307-CURRENT #0: Wed Mar 8 00:14:33 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon (551.25-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 536870912 (524288K bytes) avail memory = 517152768 (505032K bytes) Preloaded elf kernel "kernel" at 0xc03be000. Pentium Pro MTRR support enabled 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 pci1: at 0.0 irq 10 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 9 chip1: port 0x5000-0x500f at device 7.3 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0x9400-0x947f mem 0xe706-0xe706007f irq 9 at device 11.0 on pci0 xl0: Ethernet address: 00:50:da:d6:6a:d0 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: supplying EUI64: 00:50:da:ff:fe:d6:6a:d0 atapci1: port 0xa800-0xa83f,0xa400-0xa403,0xa000-0xa007,0x9c00-0x9c03,0x9800-0x9807 mem 0xe704-0xe705 irq 11 at device 13.0 on pci0 ata2: at 0x9800 on atapci1 ata3: at 0xa000 on atapci1 atapci2: port 0xbc00-0xbc3f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 mem 0xe702-0xe703 irq 5 at device 15.0 on pci0 ata4: at 0xac00 on atapci2 ata5: at 0xb400 on atapci2 atapci3: port 0xd000-0xd03f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 mem 0xe700-0xe701 irq 10 at device 17.0 on pci0 ata6: at 0xc000 on atapci3 atapci4: port 0xdc00-0xdcff,0xd800-0xd803,0xd400-0xd407 irq 11 at device 19.0 on pci0 atapci5: port 0xe800-0xe8ff,0xe400-0xe403,0xe000-0xe007 irq 11 at device 19.1 on pci0 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 Generic PS/2 mouse, 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: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 ata6-slave: ata_command: timeout waiting for intr ata6-slave: identify failed ad0: 26063MB [52953/16/63] at ata0-master using UDMA33 ad4: 26063MB [52953/16/63] at ata2-master using UDMA33 ad6: 26063MB [52953/16/63] at ata3-master using UDMA33 ad8: 26063MB [52953/16/63] at ata4-master using UDMA33 ad10: 26063MB [52953/16/63] at ata5-master using UDMA33 acd0: CDROM at ata1-master using PIO4 acd1: CD-RW at ata6-master using PIO4 Mounting root from ufs:/dev/ad0s1a vinum: loaded vinum: reading configuration from /dev/ad8s1e vinum: updating configuration from /dev/ad10s1e vinum: updating configuration from /dev/ad4s1e vinum: updating configuration from /dev/ad6s1e xl0: starting DAD for fe80:0001::0250:daff:fed6:6ad0 xl0: DAD complete for fe80:0001::0250:daff:fed6:6ad0 - no duplicates found cd9660: Joliet Extension acd1: READ_TOC - ILLEGAL REQUEST asc=24 ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: READ_TOC - ILLEGAL REQUEST asc=24 ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 acd1: READ_TOC - ILLEGAL REQUEST asc=24 ascq=0
Re: RC3: problems with SSH
[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.15i In-Reply-To: Kris Kennaway's message [Re: RC3: problems with SSH] as of Sat, Mar 1 1, 2000 at 05:10:07PM -0800 Organization: SOCS, McGill University, Montreal, CANADA Status: RO Content-Length: 815 Lines: 21 On Mar 11, Kris Kennaway wrote: > On Sat, 11 Mar 2000, Mathew Kanner wrote: > > > debug: Received server public key (1152 bits) and host key (1024 bits). > > > rsa_public_encrypt() failed > > Are you using rsaref? rsaref can't handle keys longer than 1024 bits and > we're not allowed to fix it so it can by the terms of the rsaref license. > Since you're in Canada, you don't need rsaref and should be using the > international version of openssl. See chapter 6.5 in the handbook for a > longer description of the state of play. Finally a benefit to living in Canada! Anyway, I made the port in /usr/ports/security/rsaref. My mistake was thinking that it would look at my make.conf and get the right one. Sorry about that. Also, just now when I look at the handbook, it appears to be chapter 7.5. --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RC3: problems with SSH
My colleague found these problems on a machine freshly installed with RC3. The machines on the other end are mix of sunos 2.5,6,7 on sparcs. Please flame me if this has already been discused. Script started on Sun Mar 12 00:55:40 2000 bash-2.03$ slogin -v XXX SSH Version OpenSSH-1.2.2, protocol version 1.5. Compiled with SSL. debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to XXX.CS.McGill.CA [132.206.51.205] port 22. debug: Allocated local port 978. debug: Connection established. debug: Remote protocol version 1.5, remote software version 1.2.26 debug: Waiting for server public key. debug: Received server public key (1152 bits) and host key (1024 bits). The authenticity of host 'XXX.cs.mcgill.ca' can't be established. Key fingerprint is 1024 a4:5d:e5:6d:1b:a3:71:31:31:eb:cf:09:45:a1:97:3b. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'XXX.cs.mcgill.ca' to the list of known hosts. rsa_public_encrypt() failed debug: Calling cleanup 0x8052d0c(0x0) bash-2.03$ slogin -v ni ova SSH Version OpenSSH-1.2.2, protocol version 1.5. Compiled with SSL. debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to YYY.CS.McGill.CA [132.206.51.245] port 22. debug: Allocated local port 977. debug: Connection established. debug: Remote protocol version 1.5, remote software version 1.2.26 debug: Waiting for server public key. debug: Received server public key (1152 bits) and host key (1024 bits). The authenticity of host 'YYY.cs.mcgill.ca' can't be established. Key fingerprint is 1024 ab:33:ca:d0:51:4c:fa:26:1d:d4:ed:c0:72:b0:e4:bc. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'YYY.cs.mcgill.ca' to the list of known hosts. rsa_public_encrypt() failed debug: Calling cleanup 0x8052d0c(0x0) bash-2.03$ slogin -v Z SSH Version OpenSSH-1.2.2, protocol version 1.5. Compiled with SSL. debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 0 geteuid 0 anon 0 debug: Connecting to ZZZ.CS.McGill.CA [132.206.2.5] port 22. debug: Allocated local port 976. debug: Connection established. debug: Remote protocol version 1.5, remote software version 1.2.17 debug: Waiting for server public key. Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. debug: Received server public key (768 bits) and host key (1023 bits). debug: Host 'ZZZ.cs.mcgill.ca' is known and matches the host key. debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Remote: Server does not permit empty password login. debug: Trying rhosts or /etc/hosts.equiv with RSA host authentication. debug: Server refused our rhosts authentication or host key. debug: Trying RSA authentication with key '[EMAIL PROTECTED]' debug: Server refused our key. debug: Doing password authentication. [EMAIL PROTECTED]'s password: debug: Requesting pty. debug: Requesting shell. debug: Entering interactive session. Last login: Sat Mar 11 19:55:07 2000 from .cs.m Sun Microsystems Inc. SunOS 5.7 Generic October 1998 Path now includes local/scripts Z/scripts ucb openwin Library path includes /usr/ucblib rvplayer Whoa, I know vim bash-2.03$ logout Connection to ZZZ.CS.McGill.CA closed. debug: Transferred: stdin 1, stdout 266, stderr 48 bytes in 1.0 seconds debug: Bytes per second: stdin 1.0, stdout 254.7, stderr 46.0 debug: Exit status 0 bash-2.03$ exit --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Dec 24, Mike Smith wrote:
> > On Dec 24, [EMAIL PROTECTED] wrote:
> > > On -CURRENT: Fri Dec 24 08:38:50 EST 1999,
> > > I'm getting the following when I enabled pcm and sbc in the kernel:
> > >
> > > unknown0: at port 0x220-0x22f irq 5 drq 1,0 on isa0
> > > sbc0: at port 0x388-0x38f on isa0
> > > sbc0: alloc_resource
> > > device_probe_and_attach: sbc0 attach returned 6
> > > unknown1: at port 0x208-0x20f on isa0
> > > unknown2: at port 0x330-0x331 irq 9 on isa0
> >
> > I changed sys/dev/sound/isa/sbc.c to
> > {0x0120, "Avance Logic ALS120 -00"},
> > {0x0121, "Avance Logic ALS120 -01"},
> > and got
> > sbc0: at port 0x220-0x22f irq 5 drq 1,0 on\
> > isa0
> > sbc0: setting card to irq 5, drq 1, 0
> > pcm0: on sbc0
> > sbc1: at port 0x388-0x38f on isa0
> > sbc1: alloc_resource
> > device_probe_and_attach: sbc1 attach returned 6
>
> That was silly. The -00 device is a soundblaster, but the -01 device
> certainly isn't. 8)
Sorry, I don't follow. Is leaving the -01 device in there
silly? I just assumed that it for something in the first place. (Not
my card, somebody elses)
--Mat
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pcm/sbc and Avance Logic ALS-120
On Dec 24, [EMAIL PROTECTED] wrote:
> On -CURRENT: Fri Dec 24 08:38:50 EST 1999,
> I'm getting the following when I enabled pcm and sbc in the kernel:
>
> unknown0: at port 0x220-0x22f irq 5 drq 1,0 on isa0
> sbc0: at port 0x388-0x38f on isa0
> sbc0: alloc_resource
> device_probe_and_attach: sbc0 attach returned 6
> unknown1: at port 0x208-0x20f on isa0
> unknown2: at port 0x330-0x331 irq 9 on isa0
I changed sys/dev/sound/isa/sbc.c to
{0x0120, "Avance Logic ALS120 -00"},
{0x0121, "Avance Logic ALS120 -01"},
and got
sbc0: at port 0x220-0x22f irq 5 drq 1,0 on\
isa0
sbc0: setting card to irq 5, drq 1, 0
pcm0: on sbc0
sbc1: at port 0x388-0x38f on isa0
sbc1: alloc_resource
device_probe_and_attach: sbc1 attach returned 6
unknown6: at port 0x200-0x207 on isa0
unknown7: at port 0x330-0x331 irq 9 on isa0
--Mat
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ep driver troubles
On Nov 30, Eric Ogren wrote: > > After playing around with the configuration program for a little bit, if > I set the card back to ISA mode (fixed address/irq), the patched driver > now detects the card. > As soon as I set the card to PnP, the driver doesn't see it. Based on the > pnpinfo output, I assume this must be something to do with the way my > system is configured. > I looked at my BIOS settings, and saw that all IRQs were marked available > for PnP, and that it was set to use BIOS PnP. Is this the problem? Should > this option have been set to "PnP OS"? Hi, If the symptoms are that the device doesn't probe in PNP mode (or even appear as an device) then try kern/14962. Hope this helps, --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pnp and AWE64
On Nov 13, Jim King wrote: > At 01:05 PM 11/13/1999 -0800, Alex Zepeda wrote: > >What does pnpinfo show? > > pnpinfo shows a bunch of information about my USR PnP modem, but nothing at > all about the AWE64 (or anything else). > Sorry to jump in. I once difficulties with PnP that felt similiar. I had a working sound card and when I stuck in an ISA PnP ethernet card, the sound card disapeared. I fixed it by hacking the for loop in pnp_identify in isa/pnp.c. When the loop went backwards, I could detect both devices. -Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
