Re: Parallel zip-disk can't use EPP 32 bit with 2.4.x kernels
On Tue, Jan 30, 2001 at 07:17:28PM +0100, Davy Preuveneers wrote: > Since I'm running the 2.4.x kernels, I'm having a little problem with my > parallel zip-disk. The ppa module can't use the EPP 32 protocol and uses > the PS/2 protocol instead (which is much slower), as shown by the boot > message of kernel 2.4.1: > [snip] > > Kernels 2.2.x use the EPP 32 bit protocol while the 2.4.x versions don't, > although I have used the same options when compiling the new 2.4.1 kernel. > When I change the parallel port configuration in the BIOS from ECP/EPP to > EPP only (version 1.9), the 2.4.x kernels use the EPP 32 bit protocol as > well, but then I can't use ECP with dma anymore. > > Does anyone know what the problem is? Are you sure you've given parport_pc the correct IRQ/DMA? It doesn't seem to be able to detect them very well over here, so I need a line such as: options parport_pc io=0x378 irq=7 dma=3 but YMMV :) > > Davy -- Zinx Verituse (See headers for gpg key info) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.4.0-ac8 PS/2 mouse woes
On Sat, Jan 13, 2001 at 12:02:35AM +, Alan Cox wrote: > > pc_keyb.c.. I also have the cuecat patch applied, and use it over > > the PS/2 mouse port, but I don't think it's interfering.. I doubt > > this will be noticable to people not using the "Resolution" option to > > speed up the mouse, and mine's rather insane: > > Can you tell me if the problem can be duplicated without the cuecat patch > applied. It is quite possible the ps/2 mouse patch is buggy Yes, and I tried out 2.4.0-ac7 too, just for kicks, and it doesn't break with ac7.. > > > Anyway, just letting you know, and very sorry for the lack of > > information.. > > Its most of the info I need. Since I churn through patches fast we can normally > get a good guess at the culprit. > > Alan > Also, the Oops I got is apparently due to my own code, so I'll be trying to fumble my way through fixing it :) -- Zinx Verituse (See headers for gpg key info) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.4.0-ac8 PS/2 mouse woes
I just booted to 2.4.0-ac8 (from 2.4.0-ac6) and noticed the mouse was going rather slow in X, so I pumped up the "Resolution" a bit more and restarted it.. Didn't help, and when I exited the kernel gave a nice big OOPS in kapm-idled (sorry, i don't have the output), and don't know if it's related to the mouse problem, but I do know the mouse problem goes away when I back out the changes in the ac8 patch to pc_keyb.c.. I also have the cuecat patch applied, and use it over the PS/2 mouse port, but I don't think it's interfering.. I doubt this will be noticable to people not using the "Resolution" option to speed up the mouse, and mine's rather insane: (zinx@bliss)/etc/X11$ cat XF86Config | grep Resolution Option "Resolution" "5" Anyway, just letting you know, and very sorry for the lack of information.. -- Zinx Verituse (See headers for gpg key info) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
page 0 mapped memory in ELF binaries
Ok, I'm sure this isn't any sort of show stopper for the 2.4.0 series (or any other series for that matter, and they probably all have it), but when mapping memory to page 0 in the program header of an ELF, linux completely ignores the ph_memsz field.. I've attached a program to demonstrate.. nasm is needed for compilation... (nasm is available at http://www.cryogen.com/Nasm/) Just so you know, what I want to do is have x bytes at 0x0, when only y bytes are in the file, and y will almost always be less than x.. And yes, this is a little odd, but I really want to do it ;) -- Zinx Verituse(See headers for gpg/pgp key info) BITS 32 ;; Compile with: nasm -f bin zeromap.asm -o zeromap ;; ;; Set this to size you want mapped, and that much will get mapped. This is ;; the ph_filesz field, the ph_memsz is already at 4096*2, but Linux seems to ;; completely ignore that when it's mapping to 0x0 %define ZERO_MAPPED_FILE_SIZE 0 ;; You'll want to set this if you set the above, else you'll get bus errors, ;; due to the file not actually being as big as you told the kernel it was. ;; Note that I don't want a bigger file, just a bigger amount of memory. %define PADDING 0 ;; Define this if you want it to just loop over and over, so you can, ;; say, type "cat /proc/`pidof zeromap`/maps" and get a picture of ;; what all is happening ;) %define INFINITE_LOOP 0 ;; ;; Elf Header ORG 0x8048000 elf_header: .e_ident: db 0x7f, "ELF" .e_ident_class: db 1 ;ELFCLASS32 .e_ident_encoding: db 1 ;ELFDATA2LSB .e_ident_version: db 1 ;EV_CURRENT .e_ident_padding: db 0, 0, 0, 0, 0, 0, 0, 0, 0 .e_type:dw 2 ;ET_EXEC .e_machine: dw 3 ;EM_386 .e_version: dd 1 ;EV_CURRENT .e_entry: dd main .e_phoff: dd PROGRAM_HEADER .e_shoff: dd 0 .e_flags: dd 0 .e_ehsize: dw elf_header_size .e_phentsize: dw 32 .e_phnum: dw 3 .e_shentsize: dw 0 .e_shnum: dw 0 .e_shstrndx:dw 0 elf_header_size equ $ - elf_header ;; Program Header PROGRAM_HEADER equ $-$$ program_header_1: .p_type:dd 1 ;PT_LOAD .p_offset: dd main - $$ .p_vaddr: dd main .p_paddr: dd 0 .p_filesz: dd main_size .p_memsz: dd main_size .p_flags: dd 1+2+4 ;PF_X + PF_R + PF_W .p_align: dd 4 ; Linux 2.4.0-test10 (at least) doesn't like this one at all. program_header_2: .p_type:dd 1 ;PT_LOAD .p_offset: dd nomem - $$ .p_vaddr: dd 0 .p_paddr: dd 0 .p_filesz: dd ZERO_MAPPED_FILE_SIZE .p_memsz: dd 4096*2 ;PAGE_SIZE*2 .p_flags: dd 2+4 ;PF_W + PF_R .p_align: dd 4 ; Yet, this one is fine... it's the exact same stuff, just mapped somewhere ; other than 0x0 program_header_3: .p_type:dd 1 ;PT_LOAD .p_offset: dd nomem - $$ .p_vaddr: dd nomem .p_paddr: dd 0 .p_filesz: dd 0 .p_memsz: dd 4096*2 ;PAGE_SIZE*2 .p_flags: dd 2+4 ;PF_W + PF_R .p_align: dd 4 main: %if INFINITE_LOOP jmp $ %endif mov ebp, nomem call try_access mov ebp, 0x0 call try_access mov eax, 1 ; __NR_exit xor ebx, ebx int 0x80; exit(0); try_access: call write_ebp_msg xor eax, eax .loop: mov ecx, dword [ebp+eax*4] inc eax cmp eax, 0x2000 jg .loop ret write_ebp_msg: mov eax, ebp mov ebx, 16 mov ecx, 8 .loop: xor edx, edx div ebx mov dl, [hex+edx] mov [msg_try_mapped.addr+ecx-1], dl loop .loop mov eax, 4 ; __NR_write mov ebx, 2 mov ecx, msg_try_mapped mov edx, msg_try_mapped.len int 0x80; write(2, msg_try_mapped, strlen(msg_try_mapped)); ret ; NOT REACHED msg_try_mapped: db "Accessing 4096*2 bytes of mapped(?) memory at 0x"
7-order allocation failed
I'm getting '__alloc_pages: 7-order allocation failed.' every time I play something to my maestro card (using the maestro kernel module, with dsps_order=2).. I'm assuming the following code is to blame: /* alloc as big a chunk as we can */ for (order = (dsps_order + (16-PAGE_SHIFT) + 1); order >= (dsps_order + 2 + 1); order--) if((rawbuf = (void *)__get_free_pages(GFP_KERNEL|GFP_DMA, order))) break; Of course, it doesn't seem to cause any problems, but the warning is really starting to get on my nerves... -- Zinx Verituse(See headers for gpg/pgp key info) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3-order allocation failed
On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi Kärkkäinen wrote: > > On Thu, 26 Oct 2000, Andrew Morton wrote: > > > "Pasi Kärkkäinen" wrote: > > > > gcc-2.7.2.3 miscompiles kernel/module.c and it has been decided that > > this will not be worked around. The new baseline gcc release for x86 > > is gcc-2.91.66 (otherwise known as egcs-1.1.2). > > > > Ok. I recompiled the kernel and modules with 2.95.2 and it still seems not > to work. This is from syslog: > > __alloc_pages: 2-order allocation failed. > __alloc_pages: 2-order allocation failed. > __alloc_pages: 5-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 3-order allocation failed. > __alloc_pages: 2-order allocation failed. > __alloc_pages: 5-order allocation failed. > > > Any ideas? > > - Pasi Kärkkäinen I'm getting __alloc_pages: 7-order allocation failed. all the time in 2.4.0-test9 on my "pIII (Katmai)".. kernel's compiled with 2.95.2 + bounds, without -fbounds-checking also of note is that I get: LDT allocated for cloned task! quite a bit as well.. It doesn't seem to be doing any harm, but it's probably not supposed to be happening either :/ -- Zinx Verituse(See headers for gpg/pgp key info) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] unloading ns558 driver in Linux 2.4.0-test9
On Sat, Oct 07, 2000 at 12:42:16PM -0400, Brian Gerst wrote: > "Forever shall I be." wrote: > > > > I got this OOPS while unloading the ns558 module.. I don't think it did > > this in 2.4.0-test8, but I don't recall ever unloading it in test8.. > > > > I've attached the ksymoops output.. > What kind of game port do you have? > > -- > Brian Gerst Whatever kind of game port there is on the Diamond Sonic Impact s70.. It works fine with the driver -- It just oops'd when I unloaded it :/ It should be noted here that i have to enable it with the following: setpci -v -d 125d:1968 0x40.W=0x107f -- Zinx Verituse(See headers for gpg/pgp key info) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OOPS] unloading ns558 driver in Linux 2.4.0-test9
I got this OOPS while unloading the ns558 module.. I don't think it did this in 2.4.0-test8, but I don't recall ever unloading it in test8.. I've attached the ksymoops output.. -- Zinx Verituse(See headers for gpg/pgp key info) ksymoops 2.3.4 on i686 2.4.0-test9. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_ksyms_lsmod): module ns558 is in lsmod but not in ksyms, probably no symbols exported Unable to handle kernel NULL pointer dereference at virtual address 0004 c01dbaa7 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: ecx: cf799000 edx: esi: d0820a20 edi: d082 ebp: bfffe7cc esp: ccce7f80 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 13294, stackpage=ccce7000) Stack: fff0 d0820696 d0820a20 d082 c011afd3 d082 fff0 c507 bfffe7cc c011a477 d082 ccce6000 bb15 c010a32f bb15 bb15 bb15 bfffe7cc 0081 Call Trace: [] [] [] [] [] [] [] [] Code: 89 50 04 89 02 8b 1d c8 c2 2a c0 81 fb c8 c2 2a c0 74 29 8d >>EIP; c01dbaa7<= Trace; d0820696 <[joydev]__module_device+2253/dc11> Trace; d0820a20 <[joydev]__module_device+25dd/dc11> Trace; d082 <[joydev]__module_device+1bbd/dc11> Trace; c011afd3 Trace; d082 <[joydev]__module_device+1bbd/dc11> Trace; c011a477 Trace; d082 <[joydev]__module_device+1bbd/dc11> Trace; c010a32f Code; c01dbaa7 <_EIP>: Code; c01dbaa7<= 0: 89 50 04 mov%edx,0x4(%eax) <= Code; c01dbaaa 3: 89 02 mov%eax,(%edx) Code; c01dbaac 5: 8b 1d c8 c2 2a c0 mov0xc02ac2c8,%ebx Code; c01dbab2 b: 81 fb c8 c2 2a c0 cmp$0xc02ac2c8,%ebx Code; c01dbab8 11: 74 29 je 3c <_EIP+0x3c> c01dbae3 Code; c01dbaba 13: 8d 00 lea(%eax),%eax 2 warnings issued. Results may not be reliable.
