2.6.3-Love6 aka "The Twins Come Out For A Walk"

Message

steel300 · Post by **steel300** » Fri Feb 27, 2004 7:47 pm

The last release bombed, so here's a new one coming.

The latest from Andrew Morton
PaX security model
The latest CFQ scheduler
Nick Piggin's scheduler policy
The latest reiser4 snapshot
Compressed Crypto Loopback Device support
Support for Acer Hotkeys
acx100 support
Aureal Vortex sound card support
Bootsplash support
Choose the cflags for the kernel
Framebuffer sysfs support
gcc 3.4 rcupdate warning fix
iPaq support
iRiver support
it87 shuffle fix
Layer 7 Packet Classifier
dxr3/H+ support
Latest LIRC support
Love-sources boot logo
LUFS support
Some fixes for nforce2 boards
Enable monitor mode on orinoco/hermes chipsets
UDF packet writing support
>60 Hz refresh rates in vesafb
Latest CVS prism54 drivers
sii 3512 updates
Agpgart support for sis boards
DRM for via boards
Viafb support

Evil Dark Archon · Post by **Evil Dark Archon** » Fri Feb 27, 2004 7:56 pm

i have just put up a bugzilla, you probably can't get there yet because the dns change probably hasn't propagated yet, but the url is: http://bugzilla.andrewnelson.org i have it set up (somewhat) for both love-sources and evil-sources.

Wedge_ · Post by **Wedge_** » Fri Feb 27, 2004 8:37 pm

Got this:

Code: Select all

arch/i386/kernel/process.c:497: error: conflicting types for '__switch_to'
include/asm/system.h:14: error: previous declaration of '__switch_to' was here
arch/i386/kernel/process.c:497: error: conflicting types for '__switch_to'
include/asm/system.h:14: error: previous declaration of '__switch_to' was here
make[1]: *** [arch/i386/kernel/process.o] Error 1
make: *** [arch/i386/kernel] Error 2

steel300 · Post by **steel300** » Fri Feb 27, 2004 8:41 pm

Wedge_ wrote:Got this:

Code: Select all

arch/i386/kernel/process.c:497: error: conflicting types for '__switch_to'
include/asm/system.h:14: error: previous declaration of '__switch_to' was here
arch/i386/kernel/process.c:497: error: conflicting types for '__switch_to'
include/asm/system.h:14: error: previous declaration of '__switch_to' was here
make[1]: *** [arch/i386/kernel/process.o] Error 1
make: *** [arch/i386/kernel] Error 2

I checked both places where __switch_to is defined, and they have the same type. Could you post your config file for me to take a look at?

Pink · Post by **Pink** » Fri Feb 27, 2004 8:41 pm

No problems here, although i haven't tried the packetcd writing yet (compiling into the kernel that is)

Another shiny one from Steel.

steel300 · Post by **steel300** » Fri Feb 27, 2004 8:42 pm

PickledOnion wrote:No problems here, although i haven't tried the packetcd writing yet (compiling into the kernel that is)

Another shiny one from Steel.

I made sure that pktcdvd compiled this time. You shouldn't have any problems with it.

Wedge_ · Post by **Wedge_** » Fri Feb 27, 2004 8:51 pm

@steel300: http://odin.prohosting.com/wedge01/.config

steel300 · Post by **steel300** » Fri Feb 27, 2004 9:02 pm

Wedge_ wrote:@steel300: http://odin.prohosting.com/wedge01/.config

I'm looking at it now. Which gcc do you use?

Wedge_ · Post by **Wedge_** » Fri Feb 27, 2004 9:06 pm

gcc version 3.4.0 20040225

neenee · Post by **neenee** » Fri Feb 27, 2004 9:10 pm

runs fine here

Wedge_ · Post by **Wedge_** » Fri Feb 27, 2004 9:14 pm

@steel300: using gcc-3.3.3 seems to have fixed things.

steel300 · Post by **steel300** » Fri Feb 27, 2004 9:16 pm

Wedge_ wrote:@steel300: using gcc-3.3.3 seems to have fixed things.

That's what I figured. We'll have to wait for a stable gcc 3.4 to be released before we can finally get rid of all of these bugs.

_Adik_ · Post by **_Adik_** » Fri Feb 27, 2004 9:19 pm

steel300, is there a problem with gigaraid? i dont see it in this release...

steel300 · Post by **steel300** » Fri Feb 27, 2004 9:30 pm

_Adik_ wrote:steel300, is there a problem with gigaraid? i dont see it in this release...

I don't understand where it's supposed to go. I have yet to find a patch for the 2.6 kernels. I tried putting the 2.4 files in the 2.6 kernel tree and it didn't work out to well. If you have a link to a 2.6 patch, I'll be more than happy to include it.

_Adik_ · Post by **_Adik_** » Fri Feb 27, 2004 9:38 pm

ok, thanks that you dont forget about me

i will try to find version for 2.6 kernel, i will msg you
about progress! really thanks man!
YOU ARE OUR MASTAH

PrakashP · Post by **PrakashP** » Fri Feb 27, 2004 10:03 pm

Steel300, could you send me Nick's scheudler patch or point me to it? Don't kill me for it, but I want to revert it out in future love releases. (Of course the perfect solution would be if you would manage to make the patch optional.

) I am currently running mm4 and am very happy with it. FOr me the default on with cfq feels smoother in normal desktop use.

c0bblers · Post by **c0bblers** » Fri Feb 27, 2004 10:22 pm

Hi,
Packet writing still doesn't work for me, I think its an I/O scheduler issue...something about how packet writing works doesn't like CFQ since I managed to patch packet writing into plain mm4 (which defaults to the anticipatory scheduler) and that works fine. Anyway, here's the oops (for people who understand such things).

Code: Select all

pktcdvd: writer 0 mapped to hdc
cdrom: open failed.
cdrom: open failed.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010002
EIP is at 0x0
eax: dfcaff58   ebx: dfc9f800   ecx: c0191dec   edx: dfc9f890
esi: c17f1800   edi: 00002468   ebp: 00000000   esp: df5b1d3c
ds: 007b   es: 007b   ss: 0068
Process mount.bin (pid: 8914, threadinfo=df5b0000 task=dee1cd20)
Stack: c0386d5a c17f1800 dfcaff58 dfcaff58 c17f1800 c037215f c17f1800 dfcaff58
       c0374625 c17f1800 dfcaff58 df5b0000 00000286 df5b1df0 c03746be c17f1800
       dfcaff58 df5b1da0 dfcaff58 c03872b3 dfcaff58 dfcaff58 00000002 00000001
Call Trace:
 [<c0386d5a>] pkt_lowlevel_elv_completed_req_fn+0x3a/0x80
 [<c037215f>] elv_completed_request+0x1f/0x30
 [<c0374625>] __blk_put_request+0x55/0xb0
 [<c03746be>] blk_put_request+0x3e/0x60
 [<c03872b3>] pkt_generic_packet+0x143/0x160
 [<c03894b4>] pkt_set_speed+0x94/0xb0
 [<c0388a7e>] pkt_get_last_written+0x6e/0xe0
 [<c038982c>] pkt_open_dev+0x17c/0x1d0
 [<c0376e8f>] exact_lock+0xf/0x20
 [<c0370a31>] kobj_lookup+0x131/0x1d0
 [<c0389a27>] pkt_open+0xb7/0x110
 [<c023a9f3>] do_open+0x143/0x400
 [<c023a350>] bdev_test+0x0/0x20
 [<c023a370>] bdev_set+0x0/0x10
 [<c023ad64>] blkdev_open+0x34/0x70
 [<c0231c17>] dentry_open+0x147/0x210
 [<c0231ac2>] filp_open+0x62/0x70
 [<c0231f5b>] sys_open+0x5b/0x90
 [<c01e81c7>] syscall_call+0x7/0xb
 
Code:  Bad EIP value.
 <6>note: mount.bin[8914] exited with preempt_count 2
bad: scheduling while atomic!
Call Trace:
 [<c01f9b78>] schedule+0x6b8/0x6c0
 [<c0223753>] unmap_page_range+0x43/0x70
 [<c022391b>] unmap_vmas+0x19b/0x200
 [<c0227760>] exit_mmap+0x70/0x180
 [<c01fb8bd>] mmput+0x6d/0xb0
 [<c01ff822>] do_exit+0x152/0x410
 [<c01f7b80>] do_page_fault+0x0/0x50c
 [<c01e92b9>] die+0xf9/0x100
 [<c01f7d5e>] do_page_fault+0x1de/0x50c
 [<c0393c4b>] ata_output_data+0x8b/0xb0
 [<c0393d29>] atapi_output_bytes+0x39/0x80
 [<c03a12df>] cdrom_transfer_packet_command+0x9f/0x110
 [<c01f8d12>] try_to_wake_up+0x132/0x230
 [<c01f7b80>] do_page_fault+0x0/0x50c
 [<c01e8bd1>] error_code+0x2d/0x38
 [<c0386d5a>] pkt_lowlevel_elv_completed_req_fn+0x3a/0x80
 [<c037215f>] elv_completed_request+0x1f/0x30
 [<c0374625>] __blk_put_request+0x55/0xb0
 [<c03746be>] blk_put_request+0x3e/0x60
 [<c03872b3>] pkt_generic_packet+0x143/0x160
 [<c03894b4>] pkt_set_speed+0x94/0xb0
 [<c0388a7e>] pkt_get_last_written+0x6e/0xe0
 [<c038982c>] pkt_open_dev+0x17c/0x1d0
 [<c0376e8f>] exact_lock+0xf/0x20

Cheers,
James

_Nomad_ · Post by **_Nomad_** » Fri Feb 27, 2004 10:39 pm

@steel... did you ever find out what went wrong with love5? this release seems to be exactly the same... just curious...

Master_Of_Disaster · Post by **Master_Of_Disaster** » Fri Feb 27, 2004 10:51 pm

Once more Con's patch makes it impossible for me to compile love-sources. I think I'll stick to WOLK until this is fixed on AMD64.
I noticed it complains about a redundant definition of VM_STACK_DEFAULT_FLAGS.

Code: Select all

# grep -ri 'vm_stack_default' ./*
./include/asm/page.h:#define VM_STACK_DEFAULT_FLAGS \
./include/linux/mm.h:  #ifndef VM_STACK_DEFAULT_FLAGS
./include/linux/mm.h:    #define VM_STACK_DEFAULT_FLAGS (0x00000033 | __VM_STACK_FLAGS)
./include/linux/mm.h:#ifndef VM_STACK_DEFAULT_FLAGS             /* arch can override this */
./include/linux/mm.h:#define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
./include/linux/mm.h:#define VM_STACK_FLAGS     (VM_GROWSUP | VM_STACK_DEFAULT_FLAGS | VM_ACCOUNT)
./include/linux/mm.h:#define VM_STACK_FLAGS     (VM_GROWSDOWN | VM_STACK_DEFAULT_FLAGS | VM_ACCOUNT)
./include/asm-x86_64/page.h:#define VM_STACK_DEFAULT_FLAGS \

I wrote a patch to override the definition in page.h (i.e. adding #undef) and it seemed safe to me. Does anybody has a suggestion whether this is a good idea? Or should I dismiss the definition in mm.h?

pestilence · Post by **pestilence** » Fri Feb 27, 2004 11:04 pm

After 4 love succesfull version of 2.6.3 (2.6.3-love4 running now) it seems i can't get r5 and r6 to compile

Code: Select all

  CC [M]  drivers/video/aty/radeon_base.o
drivers/video/aty/radeon_base.c: In function `radeonfb_pci_register':
drivers/video/aty/radeon_base.c:2282: error: too few arguments to function `register_framebuffer'
drivers/video/aty/radeon_base.c: At top level:
drivers/video/aty/radeon_base.c:227: warning: `common_regs_m6' defined but not used
make[3]: *** [drivers/video/aty/radeon_base.o] Error 1
make[2]: *** [drivers/video/aty] Error 2
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2

xdrainox · Post by **xdrainox** » Fri Feb 27, 2004 11:55 pm

Is there something specific I need to enable in the config to get monitor mode working on my wireless card?.. I got love6 compiled and I'm running it but airsnort and kismet can't get it into monitor mode..

-Josh

steel300 · Post by **steel300** » Fri Feb 27, 2004 11:55 pm

PrakashKC wrote:Steel300, could you send me Nick's scheudler patch or point me to it? Don't kill me for it, but I want to revert it out in future love releases. (Of course the perfect solution would be if you would manage to make the patch optional. ) I am currently running mm4 and am very happy with it. FOr me the default on with cfq feels smoother in normal desktop use.

I'd be more than happy to email it to you. Just pm me with your email address and I'll send it right away.

steel300 · Post by **steel300** » Fri Feb 27, 2004 11:56 pm

_Nomad_ wrote:@steel... did you ever find out what went wrong with love5? this release seems to be exactly the same... just curious...

I really have no idea what caused love5 to hang on boot. I'm guessing that it was a failed hunk that I had overlooked.

pestilence · Post by **pestilence** » Fri Feb 27, 2004 11:57 pm

Ok fixed the problem...Just change this:

Code: Select all

drivers/video/aty/radeon_base.c @2282
if (register_framebuffer(info) < 0) {

to

Code: Select all

drivers/video/aty/radeon_base.c @2282
if (register_framebuffer(info, NULL) < 0) {

steel300 · Post by **steel300** » Fri Feb 27, 2004 11:58 pm

pestilence wrote:After 4 love succesfull version of 2.6.3 (2.6.3-love4 running now) it seems i can't get r5 and r6 to compile

Code: Select all

  CC [M]  drivers/video/aty/radeon_base.o
drivers/video/aty/radeon_base.c: In function `radeonfb_pci_register':
drivers/video/aty/radeon_base.c:2282: error: too few arguments to function `register_framebuffer'
drivers/video/aty/radeon_base.c: At top level:
drivers/video/aty/radeon_base.c:227: warning: `common_regs_m6' defined but not used
make[3]: *** [drivers/video/aty/radeon_base.o] Error 1
make[2]: *** [drivers/video/aty] Error 2
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2

I've tried to track this error down for a while. It doesn't appear on my machines, so it's very diffcult to fix. Could you post your config file for me to look at?

EDIT: Too slow. Good Work tracking that down.