Greetings,
On 13-Sep-01 Alan Cox wrote:
>> I think weve hit a bug with HIMEM and vmalloc(); after I turned on
>> HIGHMEM
>> I get similar results: every second frame or so is either bright pink,
>> dark
>> green, but nothing normal. Memory allocation looks normal from debugging.
>>
>
> Just a t
> I think we´ve hit a bug with HIMEM and vmalloc(); after I turned on HIGHMEM
> I get similar results: every second frame or so is either bright pink, dark
> green, but nothing normal. Memory allocation looks normal from debugging.
>
Just a thought but are you using virt_to_bus() on a vmalloc pa
Greetings,
I think we´ve hit a bug with HIMEM and vmalloc(); after I turned on HIGHMEM
I get similar results: every second frame or so is either bright pink, dark
green, but nothing normal. Memory allocation looks normal from debugging.
- Nemosoft
On 12-Sep-01 Oliver Neukum wrote:
>> The secon
Hi,
On 12-Sep-01 Randy.Dunlap wrote:
> Maybe by using "mem=960M" as a kernel boot parameter (see
> linux/Documentation/kernel-parameters.txt).
I´ll ask him.
>> which to me suggests the second frame buffer is allocated, but somehow in
>> memory which isn´t accessible (every other frame is bright
Greetings,
On 12-Sep-01 Oliver Neukum wrote:
>> The second bug report said the module works fine when the person limits
>> his
>> memory to 960 MB (how, I dont know). With full memory, he gets artefacts
>
> With a 'mem=' kernel command line I presume.
>
>> which to me suggests the second frame
> The second bug report said the module works fine when the person limits his
> memory to 960 MB (how, I don´t know). With full memory, he gets artefacts
With a 'mem=' kernel command line I presume.
> which to me suggests the second frame buffer is allocated, but somehow in
> memory which isn´t
"Nemosoft Unv." wrote:
>
> The odd part is that it manages to allocate frame buffer 0, but not buffer 1!
> The code itself is in pwc-if.c, around line 312 in pwc_allocate_buffers().
> FRAME_SIZE is 460812.
>
> The second bug report said the module works fine when the person limits his
> memory
Greetings,
On 11-Sep-01 Alan Cox wrote:
>> This is the second message of this kind that I received. Seems like
>> vmalloc() does weird things on machines with 1GB or more of physical RAM.
>
> It shouldnt do so. The amount of vmalloc memory is partly dependant on the
> amount of RAM because you n
> This is the second message of this kind that I received. Seems like
> vmalloc() does weird things on machines with 1GB or more of physical RAM.
It shouldnt do so. The amount of vmalloc memory is partly dependant on the
amount of RAM because you need address space for the mappings, but that
is
Greetings,
This is the second message of this kind that I received. Seems like
vmalloc() does weird things on machines with 1GB or more of physical RAM.
[I know this isn4t strictly USB related, but others may be affected as well;
besides, lkml is probably too busy]
I4m using vmalloc() for the
10 matches
Mail list logo
