On Thu, 4 Nov 1999, Luigi Rizzo wrote:
> guys, you should realize that the ESS1868 codecs (and friends)
> are extremely unfriendly to the programmer, and possibly
> (according to Sanpei comments) broken in their handling of
> auto-dma. As a consequence i cannot believe anyone wants to
> write a d
AFAIK, not all video cards generate the vertical retrace interrupt.
Even worse, some BIOSes have a configuration option which instract the
BIOS NOT to assign an IRQ to the PCI video card.
I fully agree that the vertical retrace interrupt will be of great
value, but I wonder if it is really worth
It seems Kazutaka YOKOTA wrote:
>
> AFAIK, not all video cards generate the vertical retrace interrupt.
> Even worse, some BIOSes have a configuration option which instract the
> BIOS NOT to assign an IRQ to the PCI video card.
>
> I fully agree that the vertical retrace interrupt will be of gre
>> Well, I may be wrong :-)
>
>Well, sortof :)
>
>The delay caused by the system to process the interrupt and deliver
>the signal etc is unpredictable (well sortof) and is almost certainly
>too long so the window of opportunity will be missed ...
>
>This has been discussed to death many times in
Kazutaka YOKOTA wrote:
>
> I fully agree that the vertical retrace interrupt will be of great
> value, but I wonder if it is really worth the trouble, because it might
> be available in only few cards and systems at the end of the day...
>
I may have value synchronizing animation, such as game
Mike,
I'm not trying to contribute to the FUD, rather I'm just trying to
understand what you're proposing and what effect it will have on my
current environment.
Right now we have an OS research cluster of 30+ Pentium II machines.
These machines are used for both real research & for class proj
All,
I'm having trouble with my old Yamaha OPL based ISA soundcard. It used to
work flawlessly, but now as Don, I get `bursty' sound.
Most pronounced effect is when using `rvplayer'. If I open rvplayer and
click to play a sound clip everything is just peachy until I move the
mouse, causing a wi
> It seems Kazutaka YOKOTA wrote:
> >
> > AFAIK, not all video cards generate the vertical retrace interrupt.
> > Even worse, some BIOSes have a configuration option which instract the
> > BIOS NOT to assign an IRQ to the PCI video card.
> >
> > I fully agree that the vertical retrace interrupt
>
> AFAIK, not all video cards generate the vertical retrace interrupt.
> Even worse, some BIOSes have a configuration option which instract the
> BIOS NOT to assign an IRQ to the PCI video card.
>
> I fully agree that the vertical retrace interrupt will be of great
> value, but I wonder if it i
It seems Amancio Hasty wrote:
> > It seems Kazutaka YOKOTA wrote:
> > >
> > > AFAIK, not all video cards generate the vertical retrace interrupt.
> > > Even worse, some BIOSes have a configuration option which instract the
> > > BIOS NOT to assign an IRQ to the PCI video card.
> > >
> > > I full
What will happen if the X server was running with real time priorities which
syncing up with a vertical retrace seems to imply?
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]> Will Andrews writes:
: My card IS getting recognized, and seems to be on the appropriate port,
: BUT, I think memory pointers are getting mixed up, because it's
: returning the _WRONG_ MAC address.
That's usually an indication that something is wrong.
: Plus, 'pcca
Before I spend a lot of time hunting this down, I figured it might be worth
asking -- is there any particular reason why TCP sockets may be getting
stuck in the CLOSING state more often now?
I upgraded a machine from -current as of about June 26th to -current as of
last Friday (October 29th), an
On Thu, 4 Nov 1999, Kenneth D. Merry wrote:
>
> Before I spend a lot of time hunting this down, I figured it might be worth
> asking -- is there any particular reason why TCP sockets may be getting
> stuck in the CLOSING state more often now?
>
> I upgraded a machine from -current as of about J
kernel source cvsup'd within the last hour..
world from 991101
Preloaded elf module "linux.ko" at 0xc03bf2cc.
Preloaded elf module "atapi.ko" at 0xc03bf36c.
link_elf: symbol atapi_drvtab undefined
Intel Pentium detected, installing workaround for F00F bug
VESA: v1.2, 2048k memory, flags:0x0, mod
Curious, why is the reply field in the email header not set
to the originating mailing list? Just thought that it will make
it easier to reply to postings to the mailing lists so people don't
get multiple copies of the same message. I don't have such
problem because I have a mail filter which del
On Thu, Nov 04, 1999, Amancio Hasty wrote:
> Curious, why is the reply field in the email header not set
> to the originating mailing list? Just thought that it will make
> it easier to reply to postings to the mailing lists so people don't
> get multiple copies of the same message. I don't have s
Thus spake Amancio Hasty ([EMAIL PROTECTED]):
> it easier to reply to postings to the mailing lists so people don't
> get multiple copies of the same message. I don't have such
> problem because I have a mail filter which delete duplicate
> messages.
Reply-To: also destroys private Reply-To:'s.
> Thus spake Amancio Hasty ([EMAIL PROTECTED]):
>
> > it easier to reply to postings to the mailing lists so people don't
> > get multiple copies of the same message. I don't have such
> > problem because I have a mail filter which delete duplicate
> > messages.
>
> Reply-To: also destroys priva
On Thu, 4 Nov 1999, Amancio Hasty wrote:
> > It seems Kazutaka YOKOTA wrote:
> > >
> > > AFAIK, not all video cards generate the vertical retrace interrupt.
> > > Even worse, some BIOSes have a configuration option which instract the
> > > BIOS NOT to assign an IRQ to the PCI video card.
> > >
On Thu, Nov 04, 1999 at 06:54:32PM -0600, Chris Costello wrote:
> On Thu, Nov 04, 1999, Amancio Hasty wrote:
> > Curious, why is the reply field in the email header not set
> > to the originating mailing list? Just thought that it will make
> > it easier to reply to postings to the mailing lists s
In article [EMAIL PROTECTED]> you write:
>
>Before I spend a lot of time hunting this down, I figured it might be worth
>asking -- is there any particular reason why TCP sockets may be getting
>stuck in the CLOSING state more often now?
Not sure. But here's a tcpdump trace of a socket that ends
> What will happen if the X server was running with real time priorities which
> syncing up with a vertical retrace seems to imply?
The only real way to do this "right" is going to be to have the X
server load a KLD, which will then be able to hook the relevant
interrupt(s). Any other alterna
< said:
> Curious, why is the reply field in the email header not set
> to the originating mailing list?
Because that would be an incredibly obnoxious (I would even say
asinine) thing to do. If I want to make a reply to the list, I'll
make a reply to the list. If I don't, I won't. Readers of
> > What will happen if the X server was running with real time priorities which
> > syncing up with a vertical retrace seems to imply?
>
> The only real way to do this "right" is going to be to have the X
> server load a KLD, which will then be able to hook the relevant
> interrupt(s). Any o
On 05-Nov-99 Amancio Hasty wrote:
> Your idea sounds intriguing . How should we wired the KLD to
> the X server? or how will the KLD inform the X server that it
> has received a vertical retrace interrupt .
It depends what you wanted to do, but you could have the X server feed the KLD
comman
>
> On 05-Nov-99 Amancio Hasty wrote:
> > Your idea sounds intriguing . How should we wired the KLD to
> > the X server? or how will the KLD inform the X server that it
> > has received a vertical retrace interrupt .
>
> It depends what you wanted to do, but you could have the X server feed
> > The only real way to do this "right" is going to be to have the X
> > server load a KLD, which will then be able to hook the relevant
> > interrupt(s). Any other alternative involves interrupt delivery to
> > user-space, which is just not practical.
>
> Hi Mike,
> Your idea sounds intrigu
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> fault code = supervisor write, page not present
> instruction pointer = 0x8:0xc0680c04
> stack pointer = 0x10:0xc03d3f08
> frame pointer = 0x10:0x2a94
> code segment=
On 05-Nov-99 Amancio Hasty wrote:
> Not sure that this is as elegant as what you are suggesting , can
> the kernel schedule a user level routine to be executed when an interrupt
> occurs? I guess on Windoze land this is called a driver call-back.
Well.. KLD? :)
Thats about as close as it ge
Can somebody check and say why there are no
new cvs-cur CTM deltas after cvs-cur.5803.gz ?
(at least on 'ctm.freebsd.org' and 'ftp.freebsd.org')
Are there any other sites with FTP fetchable
CTM deltas ? (and with more current ones ?)
Yes, I can switch to 'cvs-up'ing FreeB
> > > The only real way to do this "right" is going to be to have the X
> > > server load a KLD, which will then be able to hook the relevant
> > > interrupt(s). Any other alternative involves interrupt delivery to
> > > user-space, which is just not practical.
> >
> > Hi Mike,
> > Your idea
Hello, I'm curious as to the current status of IP Filter in the -current branch of
FreeBSD. Since its removal from the kernel in October, there have been a few emails
about getting/wanting it back. May I ask who is currently working on that and what
sort of progress they are making? Thank yo
At 04:42 PM 11/4/99 -0800, you wrote:
Seems to me like a simple problem:
>devclass_alloc_unit: npx0 already exists, using next available unit number
>device npx0at isa? port IO_NPX irq 13
Shouldn't this be "at nexus?" ? Like apm0 is. I'm not quite sure it was
the problem that Mike
Amancio Hasty wrote:
> Not sure that this is as elegant as what you are suggesting , can
> the kernel schedule a user level routine to be executed when an interrupt
> occurs? I guess on Windoze land this is called a driver call-back.
Under UNIX it's called a signal handler :-)
- mark
> Luigi Rizzo <[EMAIL PROTECTED]> writes:
>
> > guys, you should realize that the ESS1868 codecs (and friends)
> > are extremely unfriendly to the programmer, and possibly
> > (according to Sanpei comments) broken in their handling of
> > auto-dma.
>
> ??
>
> I wouldn't say the interface is *pr
I have the misfortune to have a cardbus Ethernet card that came with my
Dell laptop. I was wondering how cardbus support was going, and if I could
help in any way.
--
Frank Mayhar [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
> My question boils down to: Will I be able to re-install a machine
> using your new i386 netboot just as easily as I can now? Or will I
> have to be physically present at each machine & diddle with the bios
> to toggle between disk & netboots? And what if the NIC doesn't
> support PXE? Am I
On Thu, 4 Nov 1999, Peter Jeremy wrote:
> On 1999-Nov-03 23:58:00 +1100, [EMAIL PROTECTED] wrote:
> > There are no new CTM-deltas on 'ctm.freebsd.org'
> >at least 22 hours.
>
> The last e-mail delta I have is cvs-cur.5804, which arrived here at
> 0808UTC (about 5 hours before your message).
On 05-Nov-99 Will Andrews chanted:
| At 04:42 PM 11/4/99 -0800, you wrote:
|
| Seems to me like a simple problem:
|
|>devclass_alloc_unit: npx0 already exists, using next available unit number
|
|>device npx0at isa? port IO_NPX irq 13
|
| Shouldn't t
> Very fresh -current always paniced after detecting SCSI devices on
> aha0: AHA-1542CF FW Rev. B.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs
> page fault: supervisor, read page not present
> Old kernel from Oct 8 works nicely
> Sorry can't provide more info about panic, it is remote computer.
Ok.. I tweaked the conf, and re-cvsup'd.. and i now have a bootable kernel..
but there is now another problem.. (see below)
> From [EMAIL PROTECTED] Thu Nov 4 19:36:38 1999
> Date: Thu, 04 Nov 1999 22:22:48 -0500
> To: Bob Vaughan <[EMAIL PROTECTED]>
> From: Will Andrews <[EMAIL PROTECTED]>
>
It seems Amancio Hasty wrote:
>
> Just trying to prevent dragging the whole X server to the kernel --
> Actually dragging the whole X server to the kernel is not a bad
> idea --- however it is something that I can not afford to do right now :(
Ahh, horror, Terry's old idea is coming back again :
[ CC:'d to mdodd, imp as it relates to their current work ]
At 10:44 PM 11/4/99 -0800, you wrote:
>I'm now running into issues with pccard and the ep driver, where ep0 (3c574B)
>is seen at boot time, at a familiar port/irq, but with a bogus mac address..
>(4b:57:4b:57:4b:57). ifconfig -a will im
> > Kind of complex though. Also the interrupt latency problem is still there.
>
> Not sure that this is as elegant as what you are suggesting , can
> the kernel schedule a user level routine to be executed when an interrupt
> occurs? I guess on Windoze land this is called a driver call-back.
>
On 05-Nov-99 Kevin Day wrote:
> This works, but still has a problem if latency and missed interrupts if you
> aren't reading when the interrupt happens. (I've worked around those too,
> but that's quite a bit more involved to fix it). You'll probably need to end
> up changing the scheduler sl
> It seems Amancio Hasty wrote:
> >
> > Just trying to prevent dragging the whole X server to the kernel --
> > Actually dragging the whole X server to the kernel is not a bad
> > idea --- however it is something that I can not afford to do right now :(
>
> Ahh, horror, Terry's old idea is comin
In article <[EMAIL PROTECTED]> you write:
>Hello, I'm curious as to the current status of IP Filter in the -current
>branch of FreeBSD. Since its removal from the kernel in October, there
>have been a few emails about getting/wanting it back. May I ask who is
>currently working on that and what
It seems Amancio Hasty wrote:
> > Lets step back for a moment, this is clearly the wrong solution to
> > everything, what exactly is it you want to do or want to accomplish??
> > Lets see if we can come up with another way of doing that...
>
> Okay,
>
> The problem that the XFree86 group is tryi
49 matches
Mail list logo
