On Fri, 2005-May-20 00:23:46 -0300, Luís Vitório Cargnini wrote:
>driver. I'm writeing a device driver for a board with SAA713X TV chipset
>from Phillips.
Before expending too much effort on this, you might like to study
http://www.purpe.com/download/
BTW, where did you find programming informati
Hi,
I just hit some problems with the new "contigmalloc()" routine in
FreeBSD-6-current, which is used by "bus_dmamem_alloc()".
Firstly it locks Giant, which cause locking order reversals when allocating
memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is
passed. Thirdly
Reading geode.c it appears (at least to me) that the led devices are
created for the WRAP.1C but not for the WRAP.1E.
Guessing from the dmesg output
$ dmesg
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Re
Scott Long wrote:
Luís Vitório Cargnini wrote:
Hi i need to write a device driver for a PCI board. I read the
developers book see the exemples and i'm starting to write the device
driver. I'm writeing a device driver for a board with SAA713X TV chipset
from Phillips. I did theskeleton example, but
On Friday 20 May 2005 02:29, Dirk GOUDERS wrote:
> Hello,
>
> just for completeness, I want to provide a simple program that causes
> a kernel panic when invoked with the argument /dev/ugen0:
The control endpoint /dev/ugen0 does not support polling. But
polling /dev/ugen0.X should work, where "X"
> The control endpoint /dev/ugen0 does not support polling. But
> polling /dev/ugen0.X should work, where "X" is a number.
>
> "ugenpoll()" in "/sys/dev/usb/ugen.c" should have something like this added:
>
> if(control endpoint) return POLLNVAL; /* and not "return EIO;" */
>
> Please f
On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote:
> Hi,
>
> I just hit some problems with the new "contigmalloc()" routine in
> FreeBSD-6-current, which is used by "bus_dmamem_alloc()".
>
> Firstly it locks Giant, which cause locking order reversals when allocating
> memory f
Hello!
My FreeBSD box is giving me quite a hard time, it panics from time to
time (normally after a few days uptime), I suspect it has something
to do with this cheap SATA controller I'm using (Promise SATA150
TX4). Anyway, I wanted to locate the problem and do something about
it (aka subm
"Aurel Bodenmann" <[EMAIL PROTECTED]> writes:
> My FreeBSD box is giving me quite a hard time, it panics from time to
> time (normally after a few days uptime), I suspect it has something
> to do with this cheap SATA controller I'm using (Promise SATA150
> TX4).
The SATA150 TX4 is not cheap, at le
Brian Fundakowski Feldman wrote:
On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote:
Hi,
I just hit some problems with the new "contigmalloc()" routine in
FreeBSD-6-current, which is used by "bus_dmamem_alloc()".
Firstly it locks Giant, which cause locking order reversals when al
On Fri, May 20, 2005 at 10:39:12AM -0600, Scott Long wrote:
> Brian Fundakowski Feldman wrote:
>
> >On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote:
> >
> >>Hi,
> >>
> >>I just hit some problems with the new "contigmalloc()" routine in
> >>FreeBSD-6-current, which is used by "
I have been having problems finding a bug (gnu/77818[1]) when running
gdb with any program from zsh. This is when a variable is set within
.zshrc from a back-tick command.
In my search to find the actual bug I did run into kern/80130[2] since
my source tree was dated one day before the fix. Argh!
On Friday 20 May 2005 19:32, Brian Fundakowski Feldman wrote:
> On Fri, May 20, 2005 at 10:39:12AM -0600, Scott Long wrote:
> > Brian Fundakowski Feldman wrote:
> > >On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote:
> > >>Hi,
> > >>
> > >>I just hit some problems with the new "co
On Fri, 2005-May-20 11:16:20 -0400, Brian Fundakowski Feldman wrote:
>On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote:
>> I just hit some problems with the new "contigmalloc()" routine in
>> FreeBSD-6-current, which is used by "bus_dmamem_alloc()".
I found the problem in 4.x a
Hi.
I've been experiencing a solid lockup on -current a couple times a day
to the point where I can't get a crash dump - even by triggering a panic
from the debugger. I think processes are deadlocking and more and more
get into the deadlock until the machine is unusable. A common situation
is th
I'd like to port an application that was written in x86 assembly for Linux.
So far all I had to do is change the Linux calling convention (registers)
to Posix style (stack).
However at one point this application outputs 5 characters to stdout (using
syscall write and fd=1). These 5 characters howe
On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
>Non-blocking mode has got to be supported. Else you get a nightmare rewriting
>the code to support blocking mode.
Your code either has to block somewhere or fail. contigmalloc() only
blocks if it couldn't satisfy the request immedia
On 21 May, Peter Jeremy wrote:
> On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
>>Can anyone explain why "uiomove()" has to sleep, and why there is no
>>non-blocking "uiomove()"?
>
> As far as I can see, uiomove() only sleeps if it is asked to do a
> kernel<->userland move that t
In the last episode (May 21), alexander said:
> I'd like to port an application that was written in x86 assembly for
> Linux. So far all I had to do is change the Linux calling convention
> (registers) to Posix style (stack).
>
> However at one point this application outputs 5 characters to stdout
On Fri May 20 05, Dan Nelson wrote:
>
> How often are you doing this? I wrote a quick microbenchmark and my
> pIII-900 box can do 8 writes() per second of "\e[5D\e[Kabcde". I
> don't think that's your bottleneck. If it is, the usual solution is to
> not do a write on every iteration. You'v
In the last episode (May 21), alexander said:
> Ohh...sorry for not telling you this. Yes. The app works alright when
> executed from the console. But my problem is with xterm or Eterm.
> They don't handle VT100 very well. I've added a nanosleep after each
> VT100 output but that didn't solve the i
On Sat, 2005-May-21 07:34:27 +1000, I wrote:
>I agree that you did not break contigmalloc() but since you are are
>working on contigmalloc() and are aware that the documentation is
>wrong, you might at least fix the documentation.
Having had a closer look at the CVS logs, several people have fiddl
On Fri, 2005-May-20 15:56:15 -0700, Don Lewis wrote:
>On 21 May, Peter Jeremy wrote:
>> On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote:
>
>>>Can anyone explain why "uiomove()" has to sleep, and why there is no
>>>non-blocking "uiomove()"?
>>
>> As far as I can see, uiomove() only s
In message: <[EMAIL PROTECTED]>
alexander <[EMAIL PROTECTED]> writes:
: On Fri May 20 05, Dan Nelson wrote:
: >
: > How often are you doing this? I wrote a quick microbenchmark and my
: > pIII-900 box can do 8 writes() per second of "\e[5D\e[Kabcde". I
: > don't think that's your
24 matches
Mail list logo
