Re: 2.6.25-rc[12] Video4Linux Bttv Regression
I've enabled MUTEX and SPINLOCK DEBUG, this is what I get [ cut here ] WARNING: at /home/bongani/kernel/git/linux-2.6/kernel/mutex.c:134 mutex_lock_nested+0xc0/0x2a3() Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq binfmt_misc loop nls_cp437 vfat fat nls_iso8859_1 ntfs dm_mod thermal processor fan container button pcspkr snd_pcm_oss snd_mixer_oss tuner snd_emu10k1 tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple snd_rawmidi mt20xx snd_ac97_codec tea5761 ac97_bus snd_pcm bttv snd_seq_device snd_timer firewire_ohci videodev snd_page_alloc firewire_core v4l1_compat snd_util_mem uhci_hcd ehci_hcd ir_common snd_hwdep ide_cd_mod compat_ioctl32 crc_itu_t usbcore snd sr_mod v4l2_common ohci1394 videobuf_dma_sg cdrom ieee1394 i2c_viapro videobuf_core emu10k1_gp tg3 btcx_risc gameport soundcore tveeprom sg evdev Pid: 4563, comm: radio Not tainted 2.6.25-rc2-00015-g1309d4e #36 kernel: Call Trace: [] warn_on_slowpath+0x58/0x6b [] ? native_sched_clock+0x4d/0x6c [] ? get_lock_stats+0x16/0x49 [] ? put_lock_stats+0xe/0x27 [] ? lock_release_holdtime+0x56/0x5e [] ? ide_dma_intr+0x0/0x8f [] ? native_sched_clock+0x4d/0x6c [] mutex_lock_nested+0xc0/0x2a3 [] ? :bttv:radio_g_tuner+0x42/0xa8 [] ? virt_to_highmap+0x9/0x18 [] ? __change_page_attr+0x179/0x697 [] :bttv:radio_g_tuner+0x42/0xa8 [] :videodev:__video_do_ioctl+0x2a6e/0x2e25 [] ? __change_page_attr_set_clr+0x6c/0xc0 [] ? kernel_map_pages+0x130/0x13b [] :v4l1_compat:v4l_compat_translate_ioctl+0xea9/0x1af5 [] ? :videodev:__video_do_ioctl+0x0/0x2e25 [] ? virt_to_highmap+0x9/0x18 [] ? __change_page_attr+0x179/0x697 [] ? __find_get_block+0x171/0x183 [] ? virt_to_highmap+0x9/0x18 [] ? __change_page_attr+0x179/0x697 [] ? __change_page_attr_set_clr+0x6c/0xc0 [] ? mempool_alloc_slab+0x11/0x13 [] ? native_sched_clock+0x4d/0x6c [] ? mark_held_locks+0x59/0x75 [] ? trace_hardirqs_on_thunk+0x35/0x3a [] ? trace_hardirqs_on+0xf9/0x124 [] ? trace_hardirqs_on_thunk+0x35/0x3a [] ? native_sched_clock+0x4d/0x6c [] ? restore_args+0x0/0x3d [] ? __delay+0x33/0x4f last message repeated 2 times [] ? native_sched_clock+0x4d/0x6c [] ? get_lock_stats+0x16/0x49 [] ? put_lock_stats+0xe/0x27 [] ? mark_held_locks+0x59/0x75 [] ? __mutex_unlock_slowpath+0xf9/0x11c [] ? trace_hardirqs_on+0xf9/0x124 [] ? native_sched_clock+0x4d/0x6c [] ? __lock_acquire+0xc93/0xcb4 [] ? native_sched_clock+0x4d/0x6c [] ? get_lock_stats+0x16/0x49 [] ? put_lock_stats+0xe/0x27 [] ? lock_release_holdtime+0x56/0x5e [] ? native_sched_clock+0x4d/0x6c [] ? __lock_acquire+0xc93/0xcb4 [] ? native_sched_clock+0x4d/0x6c [] ? get_lock_stats+0x16/0x49 [] ? put_lock_stats+0xe/0x27 [] :videodev:__video_do_ioctl+0x139/0x2e25 [] ? __lock_acquire+0xc93/0xcb4 [] ? native_sched_clock+0x4d/0x6c [] ? put_lock_stats+0xe/0x27 [] ? lock_release_holdtime+0x56/0x5e [] ? native_sched_clock+0x4d/0x6c [] :videodev:video_ioctl2+0x1b8/0x259 [] ? _spin_unlock_irqrestore+0x3f/0x68 [] ? trace_hardirqs_on+0xf9/0x124 [] vfs_ioctl+0x5e/0x77 [] do_vfs_ioctl+0x25b/0x270 [] ? trace_hardirqs_on_thunk+0x35/0x3a [] sys_ioctl+0x42/0x65 [] system_call_after_swapgs+0x7b/0x80 kernel: ---[ end trace bb0fc13470ac3add ]--- BUG: unable to handle kernel NULL pointer dereference at IP: [] __list_add+0x2e/0x5b PGD 68e90067 PUD 6833a067 PMD 0 Oops: [1] PREEMPT SMP DEBUG_PAGEALLOC CPU 1 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq binfmt_misc loop nls_cp437 vfat fat nls_iso8859_1 ntfs dm_mod thermal processor fan container button pcspkr snd_pcm_oss snd_mixer_oss tuner snd_emu10k1 tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple snd_rawmidi mt20xx snd_ac97_codec tea5761 ac97_bus snd_pcm bttv snd_seq_device snd_timer firewire_ohci videodev snd_page_alloc firewire_core v4l1_compat snd_util_mem uhci_hcd ehci_hcd ir_common snd_hwdep ide_cd_mod compat_ioctl32 crc_itu_t usbcore snd sr_mod v4l2_common ohci1394 videobuf_dma_sg cdrom ieee1394 i2c_viapro videobuf_core emu10k1_gp tg3 btcx_risc gameport soundcore tveeprom sg evdev Pid: 4563, comm: radio Not tainted 2.6.25-rc2-00015-g1309d4e #36 RIP: 0010:[] [] __list_add+0x2e/0x5b RSP: 0018:81005231d5b8 EFLAGS: 00010046 RAX: RBX: RCX: RDX: 81007f2bc378 RSI: 81007f2bc378 RDI: 81005231d5d8 RBP: 81005231d5b8 R08: R09: 0001 R10: 81005231d2d8 R11: 7420 R12: 81007f2bc338 R13: 0246 R14: 81007f2bc3a0 R15: 81005da847c0 FS: 7f3c348aa6f0() GS:81007f0554c8() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 75c6e000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process radio (pid: 4563, threadinfo 81005231c000, task 81005da847c0) Stack: 81005231d63
Re: 2.6.25-rc[12] Video4Linux Bttv Regression
More info add Ingo to CC, maybe he can explain what might cause such failure in the mutex code (sorry Ingo, I need to bother you once more) Ingo: I got the oops bellow whilst using the radio functionality of the bttv-drivers, nothing seems obvious except that I dies while calling __mutex_lock_slowpath. I've been trying to follow Linus' and Al's advise on oops tracing and I got as far as the _spin_lock code: BUG: unable to handle kernel NULL pointer dereference at IP: [] __mutex_lock_slowpath+0x3b/0xb2 PGD 67671067 PUD 63f47067 PMD 0 Oops: 0002 [1] PREEMPT SMP CPU 0 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq binfmt_misc loop nls_cp437 vfat fat nls_iso8859_1 ntfs dm_mod thermal processor fan container button pcspkr snd_pcm_oss snd_mixer_oss tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 snd_emu10k1 snd_rawmidi bttv snd_ac97_codec videodev ac97_bus v4l1_compat snd_pcm ir_common firewire_ohci firewire_core snd_seq_device compat_ioctl32 snd_timer uhci_hcd ehci_hcd v4l2_common ide_cd_mod crc_itu_t snd_page_alloc usbcore videobuf_dma_sg snd_util_mem videobuf_core ohci1394 btcx_risc i2c_viapro sr_mod snd_hwdep ieee1394 emu10k1_gp snd tg3 cdrom tveeprom gameport sg evdev soundcore Pid: 7197, comm: radio Tainted: G M 2.6.25-rc1 #20 RIP: 0010:[] [] __mutex_lock_slowpath+0x3b/0xb2 RSP: 0018:81007df515e8 EFLAGS: 00010246 RAX: 81007f13ef10 RBX: 81007f13ef08 RCX: RDX: 81007df515e8 RSI: 88184050 RDI: 81007f13ef0c RBP: 81007df51628 R08: 0004 R09: 81007df51aa8 R10: 81007e680a40 R11: 0202 R12: 81007f13ef0c R13: 81007f13ef08 R14: 810063cfc040 R15: 88184050 FS: 7fa8d92ba6f0() GS:805b2000() knlGS:f61fb980 CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 676dc000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process radio (pid: 7197, threadinfo 81007df5, task 810063cfc040) Stack: 81007f13ef10 00050499 018060f7018060fa 0024 81007df51aa8 81007f13e800 81007f13ef08 81007e0e5800 81007df51638 80457083 81007df51668 88162f2f Call Trace: [] [] :bttv:radio_g_tuner+0x40/0xa6 [] :videodev:__video_do_ioctl+0x2a6e/0x2e25 [] :v4l1_compat:v4l_compat_translate_ioctl+0xea9/0x1af5 [] ? :videodev:__video_do_ioctl+0x0/0x2e25 [] ? blk_recount_segments+0x3e/0x62 [] ? mempool_alloc_slab+0x11/0x13 [] ? mempool_alloc+0x48/0xf9 [] ? ext3_get_acl+0x87/0x332 [] ? __d_lookup+0x125/0x137 [] ? do_lookup+0x63/0x1b1 [] ? dput+0x22/0x120 [] ? __link_path_walk+0xbbd/0xd1b [] ? ext3_get_acl+0x87/0x332 [] ? native_read_tsc+0x11/0x22 [] ? __delay+0x27/0x59 last message repeated 2 times [] ? __udelay+0x40/0x42 [] ? i2c_stop+0x47/0x4b [] ? bit_xfer+0x412/0x423 [] ? i2c_transfer+0x79/0x85 [] ? :tuner_simple:simple_set_params+0x2bd/0xc1c [] ? get_unused_fd_flags+0x10d/0x11c [] ? touch_atime+0xe3/0xec [] ? mntput_no_expire+0x20/0x8f [] ? :tuner:fe_set_params+0x46/0x48 [] ? :tuner:set_radio_freq+0x159/0x162 [] ? klist_dec_and_del+0x14/0x16 [] ? klist_next+0x6b/0x8a [] ? i2c_cmd+0x0/0x3e [] ? device_for_each_child+0x4c/0x5c [] :videodev:__video_do_ioctl+0x139/0x2e25 [] ? :bttv:bttv_call_i2c_clients+0x16/0x18 [] ? :bttv:audio_mux+0x105/0x1b5 [] ? filemap_fault+0x1fe/0x371 [] :videodev:video_ioctl2+0x1b8/0x259 [] ? handle_mm_fault+0x341/0x697 [] vfs_ioctl+0x5e/0x77 [] do_vfs_ioctl+0x24d/0x262 [] ? do_page_fault+0x434/0x7aa [] sys_ioctl+0x42/0x67 [] system_call_after_swapgs+0x7b/0x80 Feb 15 08:42:03 bongani64 kernel: Feb 15 08:42:03 bongani64 kernel: Code: 89 fb 4c 89 e7 48 83 ec 20 65 4c 8b 34 25 00 00 00 00 e8 19 12 00 00 48 8d 43 08 48 8d 55 c0 48 8b 48 08 48 89 45 c0 48 89 50 08 <48> 89 11 48 83 ca ff 48 89 4d c8 4c 89 75 d0 48 89 d0 87 03 ff RIP [] __mutex_lock_slowpath+0x3b/0xb2 RSP CR2: ---[ end trace fdf145f4fc51dccd ]--- note: radio[7197] exited with preempt_count 1 Code dissamble: 0x4005c0 : mov%edi,%ebx 0x4005c2 : mov%r12,%rdi 0x4005c5 : sub$0x20,%rsp 0x4005c9 : mov%gs:0x0,%r14 0x4005d2 :callq 0x4017f0 0x4005d7 :lea0x8(%rbx),%rax 0x4005db :lea0xffc0(%rbp),%rdx 0x4005df :mov0x8(%rax),%rcx 0x4005e3 :mov%rax,0xffc0(%rbp) 0x4005e7 :mov%rdx,0x8(%rax) 0x4005eb :mov%rdx,(%rcx) <= Here 0x4005ee :or $0x,%rdx 0x4005f2 :mov%rcx,0xffc8(%rbp) 0x4005f6 :mov%r14,0xffd0(%rbp) 0x4005fa :mov%rdx,%rax 0x4005fd :xchg %eax,(%rbx) 0x4005ff :incl (%rax) 0x400601: and$0xa70,%eax 0x400606: add%al,(%rax) 0x400608: add%ebx,(%rbx) kernel/mutext.c dis
Re: 2.6.25-rc[12] Video4Linux Bttv Regression
On Monday 18 February 2008 23:20:40 Bongani Hlope wrote: > On Monday 18 February 2008 18:11:25 Mauro Carvalho Chehab wrote: > > Have you tested Robert's patch? > > Sorry almost forgot, I have and it fixes the TV but not the radio. > > > I can't see anything wrong on bttv_g_tuner lock. I suspect that the > > divide error caused some bad effects at some data on bttv. > > The problems don't seem related because one is caused by opening the > "radio" application, the divide error is caused by using a TV viewing > application (I tried fbtv) > > > I've already applied his fix to my -git tree: > > Thanx, I'll try to bisect I tried to bisect but the V4L/DVB changes are not bisect friendly, on two occursions I just selected "git bisect bad" because the bttv driver wouldn't compile, so I couldn't pin-point what causes the oops and hang. Here are some few observations I made though (I started bisecting between 2.6.24 and 2.6.25-rc1, saved me ~1000 commits): 1. On the third bisect, there's no oops my PC just hangs a I can't use any open terminals 2. When I reached the V4L/DVB changes, my PC did not hag or oops, the radio just didn't work (something about invalid VID**AUD**). This made it harder to bisect, because it is not working and not breaking so is it good or bad... Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc[12] Video4Linux Bttv Regression
On Monday 18 February 2008 18:11:25 Mauro Carvalho Chehab wrote: > On Sun, 17 Feb 2008 10:36:19 +0200 > > Bongani Hlope <[EMAIL PROTECTED]> wrote: > > The bttv driver seems to be experiencing problems in the 2.6.25-rcX > > kernels. I have the divided by error that Robert Fitzsimons has already > > reported (I'll test his patch and see if it fixes it for me) and I have > > the following Oops when I try to use the radio: > > Have you tested Robert's patch? > Sorry almost forgot, I have and it fixes the TV but not the radio. > I can't see anything wrong on bttv_g_tuner lock. I suspect that the divide > error caused some bad effects at some data on bttv. > The problems don't seem related because one is caused by opening the "radio" application, the divide error is caused by using a TV viewing application (I tried fbtv) > I've already applied his fix to my -git tree: Thanx, I'll try to bisect > > http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git > > Hopefully, Linus will pull soon the fixes there. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc[12] Video4Linux Bttv Regression
The bttv driver seems to be experiencing problems in the 2.6.25-rcX kernels. I have the divided by error that Robert Fitzsimons has already reported (I'll test his patch and see if it fixes it for me) and I have the following Oops when I try to use the radio: BUG: unable to handle kernel NULL pointer dereference at IP: [] __mutex_lock_slowpath+0x3b/0xb2 PGD 67671067 PUD 63f47067 PMD 0 Oops: 0002 [1] PREEMPT SMP CPU 0 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq binfmt_misc loop nls_cp437 vfat fat nls_iso8859_1 ntfs dm_mod thermal processor fan container button pcspkr snd_pcm_oss snd_mixer_oss tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx tea5761 snd_emu10k1 snd_rawmidi bttv snd_ac97_codec videodev ac97_bus v4l1_compat snd_pcm ir_common firewire_ohci firewire_core snd_seq_device compat_ioctl32 snd_timer uhci_hcd ehci_hcd v4l2_common ide_cd_mod crc_itu_t snd_page_alloc usbcore videobuf_dma_sg snd_util_mem videobuf_core ohci1394 btcx_risc i2c_viapro sr_mod snd_hwdep ieee1394 emu10k1_gp snd tg3 cdrom tveeprom gameport sg evdev soundcore Pid: 7197, comm: radio Tainted: G M 2.6.25-rc1 #20 RIP: 0010:[] [] __mutex_lock_slowpath+0x3b/0xb2 RSP: 0018:81007df515e8 EFLAGS: 00010246 RAX: 81007f13ef10 RBX: 81007f13ef08 RCX: RDX: 81007df515e8 RSI: 88184050 RDI: 81007f13ef0c RBP: 81007df51628 R08: 0004 R09: 81007df51aa8 R10: 81007e680a40 R11: 0202 R12: 81007f13ef0c R13: 81007f13ef08 R14: 810063cfc040 R15: 88184050 FS: 7fa8d92ba6f0() GS:805b2000() knlGS:f61fb980 CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 676dc000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process radio (pid: 7197, threadinfo 81007df5, task 810063cfc040) Stack: 81007f13ef10 00050499 018060f7018060fa 0024 81007df51aa8 81007f13e800 81007f13ef08 81007e0e5800 81007df51638 80457083 81007df51668 88162f2f Call Trace: [] mutex_lock+0xe/0x10 [] :bttv:radio_g_tuner+0x40/0xa6 [] :videodev:__video_do_ioctl+0x2a6e/0x2e25 [] :v4l1_compat:v4l_compat_translate_ioctl+0xea9/0x1af5 [] ? :videodev:__video_do_ioctl+0x0/0x2e25 [] ? blk_recount_segments+0x3e/0x62 [] ? mempool_alloc_slab+0x11/0x13 [] ? mempool_alloc+0x48/0xf9 [] ? ext3_get_acl+0x87/0x332 [] ? __d_lookup+0x125/0x137 [] ? do_lookup+0x63/0x1b1 [] ? dput+0x22/0x120 [] ? __link_path_walk+0xbbd/0xd1b [] ? ext3_get_acl+0x87/0x332 [] ? native_read_tsc+0x11/0x22 [] ? __delay+0x27/0x59 last message repeated 2 times [] ? __udelay+0x40/0x42 [] ? i2c_stop+0x47/0x4b [] ? bit_xfer+0x412/0x423 [] ? i2c_transfer+0x79/0x85 [] ? :tuner_simple:simple_set_params+0x2bd/0xc1c [] ? get_unused_fd_flags+0x10d/0x11c [] ? touch_atime+0xe3/0xec [] ? mntput_no_expire+0x20/0x8f [] ? :tuner:fe_set_params+0x46/0x48 [] ? :tuner:set_radio_freq+0x159/0x162 [] ? klist_dec_and_del+0x14/0x16 [] ? klist_next+0x6b/0x8a [] ? i2c_cmd+0x0/0x3e [] ? device_for_each_child+0x4c/0x5c [] :videodev:__video_do_ioctl+0x139/0x2e25 [] ? :bttv:bttv_call_i2c_clients+0x16/0x18 [] ? :bttv:audio_mux+0x105/0x1b5 [] ? filemap_fault+0x1fe/0x371 [] :videodev:video_ioctl2+0x1b8/0x259 [] ? handle_mm_fault+0x341/0x697 [] vfs_ioctl+0x5e/0x77 [] do_vfs_ioctl+0x24d/0x262 [] ? do_page_fault+0x434/0x7aa [] sys_ioctl+0x42/0x67 [] system_call_after_swapgs+0x7b/0x80 Feb 15 08:42:03 bongani64 kernel: Feb 15 08:42:03 bongani64 kernel: Code: 89 fb 4c 89 e7 48 83 ec 20 65 4c 8b 34 25 00 00 00 00 e8 19 12 00 00 48 8d 43 08 48 8d 55 c0 48 8b 48 08 48 89 45 c0 48 89 50 08 <48> 89 11 48 83 ca ff 48 89 4d c8 4c 89 75 d0 48 89 d0 87 03 ff RIP [] __mutex_lock_slowpath+0x3b/0xb2 RSP CR2: ---[ end trace fdf145f4fc51dccd ]--- note: radio[7197] exited with preempt_count 1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: irq 21: nobody cared 2.6.24-rc1
On Thursday 01 November 2007 22:32:38 Andrew Morton wrote: > On Thu, 25 Oct 2007 10:45:36 +0200 > > Bongani Hlope <[EMAIL PROTECTED]> wrote: > > Booting with irqpoll works > > > > ls /proc/irq/21/ (with irqpoll) > > ehci_hcd:usb1/ smp_affinity uhci_hcd:usb2/ uhci_hcd:usb3/ > > uhci_hcd:usb4/ > > > > Disabling IRQ #21 > > Was any earlier kernel version OK? 2.6.23? Yes the 2.6.23 kernel works fine. This seems to happen when I boot the 2.6.24-rc1 kernel with an iPod attached (hope this helps), but the 2.6.23 kernel doesn't experience this problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
irq 21: nobody cared 2.6.24-rc1
Booting with irqpoll works ls /proc/irq/21/ (with irqpoll) ehci_hcd:usb1/ smp_affinity uhci_hcd:usb2/ uhci_hcd:usb3/ uhci_hcd:usb4/ irq 21: nobody cared (try booting with the "irqpoll" option) Call Trace: [__report_bad_irq+56/124] __report_bad_irq+0x38/0x7c [] __report_bad_irq+0x38/0x7c [note_interrupt+546/617] note_interrupt+0x222/0x269 [] note_interrupt+0x222/0x269 [handle_fasteoi_irq+179/221] handle_fasteoi_irq+0xb3/0xdd [] handle_fasteoi_irq+0xb3/0xdd [do_IRQ+246/361] do_IRQ+0xf6/0x169 [] do_IRQ+0xf6/0x169 [ret_from_intr+0/10] ret_from_intr+0x0/0xa [] ret_from_intr+0x0/0xa [unmap_vmas+665/1878] unmap_vmas+0x299/0x756 [] unmap_vmas+0x299/0x756 [unmap_vmas+1838/1878] unmap_vmas+0x72e/0x756 [] unmap_vmas+0x72e/0x756 [exit_mmap+137/295] exit_mmap+0x89/0x127 > [] exit_mmap+0x89/0x127 [mmput+40/164] mmput+0x28/0xa4 [] mmput+0x28/0xa4 [flush_old_exec+1543/2268] flush_old_exec+0x607/0x8dc [] flush_old_exec+0x607/0x8dc [load_elf_binary+0/7165] load_elf_binary+0x0/0x1bfd [] load_elf_binary+0x0/0x1bfd [load_elf_binary+0/7165] load_elf_binary+0x0/0x1bfd [] load_elf_binary+0x0/0x1bfd [load_elf_binary+1337/7165] load_elf_binary+0x539/0x1bfd [] load_elf_binary+0x539/0x1bfd [__strnlen_user+33/45] __strnlen_user+0x21/0x2d [] __strnlen_user+0x21/0x2d [put_arg_page+9/11] put_arg_page+0x9/0xb [] put_arg_page+0x9/0xb [load_elf_binary+0/7165] load_elf_binary+0x0/0x1bfd [] load_elf_binary+0x0/0x1bfd [search_binary_handler+227/565] search_binary_handler+0xe3/0x235 [] search_binary_handler+0xe3/0x235 [do_execve+357/451] do_execve+0x165/0x1c3 [] do_execve+0x165/0x1c3 [sys_execve+54/145] sys_execve+0x36/0x91 [] sys_execve+0x36/0x91 [stub_execve+103/176] stub_execve+0x67/0xb0 [] stub_execve+0x67/0xb0 handlers: [_end+128171676/2130295572] (usb_hcd_irq+0x0/0x5d [usbcore]) [] (usb_hcd_irq+0x0/0x5d [usbcore]) [_end+128171676/2130295572] (usb_hcd_irq+0x0/0x5d [usbcore]) [] (usb_hcd_irq+0x0/0x5d [usbcore]) [_end+128171676/2130295572] (usb_hcd_irq+0x0/0x5d [usbcore]) [] (usb_hcd_irq+0x0/0x5d [usbcore]) [_end+128171676/2130295572] (usb_hcd_irq+0x0/0x5d [usbcore]) [] (usb_hcd_irq+0x0/0x5d [usbcore]) Disabling IRQ #21 --- lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:05.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 00:05.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 00:08.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04) 00:08.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04) 00:08.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) 00:0b.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet (rev 03) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV36 [GeForce FX 5700LE] (rev a1) ./ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux bongani64 2.6.24-rc1 #1 SMP PREEMPT Wed Oct 24 20:22:00 SAST 2007 x86_64 AMD Opteron(tm) Processor 244 GNU/Linux Gnu C 4.2.2 Gnu make 3.81 binutils 2.17.50.0.12 util-linux 2.13 mount 2.13 module-init-tools 3.3-pre11 e2fsprogs 1.40.2 Linux C Library2.6.1 Dynamic linker (ldd) 2.6.1 Procps 3.2.7 Net-tools 1.60 Kbd
Re: Chroot bug
On Wednesday 26 September 2007 13:06:51 David Newall wrote: > Alan Cox wrote: > >>> The dot-dot entry in the root directory is interpreted to mean the > >>> root directory itself. Thus, dot-dot cannot be used to access files > >>> outside the subtree rooted at the root directory. > > > > Which is behaviour chroot preserves properly. > > And yet it is the dot-dot entry which is used to access files outside > the root. > > > The specification says explicitly > > > > "The process working directory is unaffected by chroot()." > > Do you believe that when those words were first written, the hidden > conflict, namely that it permits dot-dot to access files outside the > subtree, was understood? They would have said so if that were the case. You seem to be misunderstanding what Alan is trying to say to you, if your program calls chroot, it's working directory is unaffected. Programs that are started in the chrooted root, will be affected. i.e. if you run chroot in bash, the bash process's CWD is not affected and bash can escape the chrooted root, but if you run ls .., it will not escape. If you do not get too emotional, you tend to understand what people are trying to say. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] 2.6.23-rc1 Seems to be network related
On Wednesday 01 August 2007 03:04:07 Andrew Morton wrote: > On Wed, 1 Aug 2007 02:57:48 +0200 Bongani Hlope <[EMAIL PROTECTED]> wrote: > > I'm not sure if the first email went through, resending without .config > > attachment. > > It did come through, and I replied ;) > Thank you ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] 2.6.23-rc1 Seems to be network related
Hi I'm not sure if the first email went through, resending without .config attachment. I got this partial Oops on my work laptop (DELL D800), while using the linux 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and this is the first and only time it did not boot. It was around the time it should have been trying to connect to my linksys wireless router (which has been working fine everyday since the 2.6.23-rc1 kernel was released). I copied what was on screen by hand, so some info is missing. I don't know how to reproduce it. Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x1c2/0x2db [] die+0x02/0x1de [] do_trap+0x89/0xa2 [] do_invalid_op+0x88/0x92 [] error_code+0x6a/0x70 [] kmap_atomic+0xe/0x10 [] get_page_from_freelist+0x24c/0x3... [] __alloc_pages+0x53/0x27d [] kmem_cache_alloc+0x32/0x68 [] dst_alloc+0x28/0x60 [] ip_route_input+0x9b9/0xbba [] arp_process+0x155/0x4e1 [] arp_rcv+0xe9/0xfd [] netif_receive_skb+0x16e/0x1eb [] process_backlog+0x71/0xda [] net_rx_action+0x56/0xee [] __do_softirq+0x38/0x7a [] do_soft_irq+0x41/0x91 [] irq_exit+0x2c/0x66 [] do_IRQ+0xb7/0xcd [] common_interrupt+0x23/0x28 [] handle_mm_fault+0x1fe/0x57e [] error_code+0x6a/0x70 === EIP: [] kmap_atomic_prot+0x27/0x8.. Linux bongani_nb 2.6.23-rc1 #4 PREEMPT Mon Jul 23 12:11:40 SAST 2007 i686 Intel(R) Pentium(R) M processor 1600MHz GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.9 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.39 pcmciautils014 PPP2.4.4 Linux C Library> libc.2.4 Dynamic linker (ldd) 2.4 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 106 wireless-tools 28 Modules Loaded tg3 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd soundcore video output thermal sbs processor fan container button battery ac pcmcia yenta_socket rsrc_nonstatic pcmcia_core intel_agp hidp nvram rfcomm l2cap ipw2100 ieee80211 ieee80211_crypt usbhid hci_usb bluetooth ohci1394 ieee1394 ehci_hcd uhci_hcd joydev evdev I'm sorry I can't provide more info, this is completely random and it's the first time it ever happened. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] 2.6.23-rc1 Seems to be network related
Hi I got this partial Oops on my work laptop (DELL D800), while using the linux 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and this is the first and only time it did not boot. It was around the time it should have been trying to connect to my linksys wireless router (which has been working fine everyday since the 2.6.23-rc1 kernel was released). I copied what was on screen by hand, so some info is missing. I don't know how to reproduce it. Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x1c2/0x2db [] die+0x02/0x1de [] do_trap+0x89/0xa2 [] do_invalid_op+0x88/0x92 [] error_code+0x6a/0x70 [] kmap_atomic+0xe/0x10 [] get_page_from_freelist+0x24c/0x3... [] __alloc_pages+0x53/0x27d [] kmem_cache_alloc+0x32/0x68 [] dst_alloc+0x28/0x60 [] ip_route_input+0x9b9/0xbba [] arp_process+0x155/0x4e1 [] arp_rcv+0xe9/0xfd [] netif_receive_skb+0x16e/0x1eb [] process_backlog+0x71/0xda [] net_rx_action+0x56/0xee [] __do_softirq+0x38/0x7a [] do_soft_irq+0x41/0x91 [] irq_exit+0x2c/0x66 [] do_IRQ+0xb7/0xcd [] common_interrupt+0x23/0x28 [] handle_mm_fault+0x1fe/0x57e [] error_code+0x6a/0x70 === EIP: [] kmap_atomic_prot+0x27/0x8.. Linux bongani_nb 2.6.23-rc1 #4 PREEMPT Mon Jul 23 12:11:40 SAST 2007 i686 Intel(R) Pentium(R) M processor 1600MHz GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.9 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.39 pcmciautils014 PPP2.4.4 Linux C Library> libc.2.4 Dynamic linker (ldd) 2.4 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 106 wireless-tools 28 Modules Loaded tg3 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd soundcore video output thermal sbs processor fan container button battery ac pcmcia yenta_socket rsrc_nonstatic pcmcia_core intel_agp hidp nvram rfcomm l2cap ipw2100 ieee80211 ieee80211_crypt usbhid hci_usb bluetooth ohci1394 ieee1394 ehci_hcd uhci_hcd joydev evdev I'm sorry I can't provide more info, this is completely random and it's the first time it ever happened. config.gz Description: GNU Zip compressed data
Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"
On Monday 30 July 2007 23:51:42 Steven wrote:
> On Thu, 26 Jul 2007 16:29:55 +0200, Rafael J. Wysocki wrote:
> > OK, so here it goes again with a changelog:
> >
> > ---
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Generally, sysdev_shutdown() should be called after the ACPI preparation
> > for powering the system off. To make it happen, we can separate
> > sysdev_shutdown() from device_shutdown() and call it directly wherever
> > necessary.
>
> Has this patch become part of the official git tree (git://git.kernel.org/
> pub/scm/linux/kernel/git/torvalds/linux-2.6.git)? If not then are there
> plans to make it part of the official git tree?
>
Yes it is.
commit 58b3b71dfaaecbf7cff1fe10c049d663f0313e5f
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date: Thu Jul 26 16:29:55 2007 +0200
Fix ThinkPad T42 poweroff failure introduced by by "PM: Introduce
pm_power_off_prepare"
Commit bd804eba1c8597cbb7cd5a5f9fe886aae16a079a ("PM: Introduce
pm_power_off_prepare") caused problems in the poweroff path, as reported
by
YOSHIFUJI Hideaki / åè¤è±æ.
Generally, sysdev_shutdown() should be called after the ACPI preparation
for
powering the system off. To make it happen, we can separate
sysdev_shutdown()
from device_shutdown() and call it directly wherever necessary.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Tested-by: YOSHIFUJI Hideaki / åè¤è±æ <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: updatedb
On Thursday 26 July 2007 10:01:11 Rene Herman wrote: > On 07/26/2007 09:08 AM, Bongani Hlope wrote: > > On Thursday 26 July 2007 08:56:59 Rene Herman wrote: > >> Great. Now concentrate on the "swpd" column, as it's the only thing > >> relevant here. The fact that an updatedb run fills/replaces caches is > >> completely and utterly unsurprising and not something swap-prefetch > >> helps with. The only thing it does is bring back stuff from _swap_. > > > > ;) > > > > I have 2Gb of RAM and I never ever touched swap on all my work loads. I > > was just showing the behavior of updatedb on my desktop. I have never > > even looked at the swap-prefetch patch (for obvious reasons). > > I see... thanks for the report :) > > > I think people should also look at their /proc/sys/vm/overcommit_ratio > > In the sense that current stuff might be evicted earlier with no or little > overcommit? > Oops, that was suppose to be /proc/sys/vm/swappiness Sorry about the confusion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updatedb
On Thursday 26 July 2007 08:56:59 Rene Herman wrote: > On 07/26/2007 08:39 AM, Bongani Hlope wrote: > > On Thursday 26 July 2007 05:59:53 Rene Herman wrote: > >> So what's happening? If you sit down with a copy op "top" in one > >> terminal and updatedb in another, what does it show? > > > > Just tested that, there's a steady increase in the useage of buff > > Great. Now concentrate on the "swpd" column, as it's the only thing > relevant here. The fact that an updatedb run fills/replaces caches is > completely and utterly unsurprising and not something swap-prefetch helps > with. The only thing it does is bring back stuff from _swap_. > ;) I have 2Gb of RAM and I never ever touched swap on all my work loads. I was just showing the behavior of updatedb on my desktop. I have never even looked at the swap-prefetch patch (for obvious reasons). I think people should also look at their /proc/sys/vm/overcommit_ratio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: updatedb
On Thursday 26 July 2007 05:59:53 Rene Herman wrote: > > Problem spot no. 1. > > RAM intensive? If I run updatedb here, it never grows itself beyond 2M. > Yes, two. I'm certainly willing to accept that me and my systems are > possibly not the reference but assuming I'm _very_ special hasn't done much > for me either in the past. > > The thing updatedb does do, or at least has the potential to do, is fill > memory with cached inodes/dentries but Linux does not swap to make room for > caches. So why will updatedb "often cause things to be swapped out"? > > [ snip ] > > > Swap prefetch, on the other hand, would have kicked in shortly after > > updatedb finished, leaving the applications in swap for a speedy > > recovery when the person comes back to their computer. > > Problem spot no. 2. > > If updatedb filled all of RAM with inodes/dentries, that RAM is now used > (ie, not free) and swap-prefetch wouldn't have anywhere to prefetch into so > would _not_ have kicked in. > > So what's happening? If you sit down with a copy op "top" in one terminal > and updatedb in another, what does it show? > > Rene. Just tested that, there's a steady increase in the useage of buff procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 1 0 1279412 201160 23472000 19329 558 657 5 1 89 5 0 1 0 1276624 203436 23487200 2276 0 1638 2456 4 2 48 48 1 1 0 1273372 206292 23501200 2852 0 1773 2755 3 3 48 46 2 1 0 1270128 208376 23536000 2084 0 1545 2168 5 2 47 46 8< 0 1 0 1228004 237288 23783600 2192 0 1669 2941 6 3 47 44 1 1 0 1223424 239228 23802000 1932 272 1580 2881 9 4 44 44 1 1 0 1219692 241600 23820800 2372 0 1719 2881 10 4 45 43 0 1 0 1217296 243372 23831200 1772 0 1526 2320 4 2 49 46 8< 0 1 0 1166852 277912 24084000 2244 0 1699 3037 7 2 48 43 0 1 0 1164016 279528 24101600 1608 824 1512 2364 7 2 47 44 1 1 0 1161256 281860 24126400 2332 0 1709 2769 7 2 49 43 1 1 0 1155632 284792 24145200 2932 0 1835 3084 8 4 46 42 8< 0 1 0 1104568 324788 24361600 3500 4 1879 3054 5 4 46 46 1 1 0 1099596 328524 24376800 3736 0 1990 3257 7 4 48 43 1 1 0 1093976 332516 24406000 3984 572 2013 3348 6 3 48 43 0 1 0 1090320 335396 24434000 2880 0 1760 2925 5 3 47 46 8< 1 1 0 1025212 384380 24822400 2940 0 1763 2864 6 3 46 46 0 1 0 1022196 386444 24832800 2064 8 1527 2543 5 2 45 47 0 1 0 1018620 389476 24840400 3032 0 1798 2988 6 3 47 45 0 1 0 1014800 392364 24855200 2888 0 1738 2821 5 2 48 45 8< 0 1 0 425200 839828 27339200 1744 0 1441 2248 9 2 44 46 0 1 0 423360 841220 27354400 1384 368 1374 2144 3 1 48 48 0 1 0 421288 842868 27357600 1648 0 1400 2141 4 2 46 48 0 1 0 418252 845172 27367600 2300 0 1570 2492 3 1 49 48 0 0 0 417300 846100 27377600 928 0 1232 1837 3 2 72 24 0 0 0 416724 846100 27377600 0 0 1025 1579 5 1 94 0 0 0 0 417012 846100 27377600 0 0 1002 1474 3 1 97 0 1 0 0 417220 846100 27377600 0 0 1026 1414 2 0 98 0 So 32 percent of free memory went to the buffers. 5 minutes later it's still not freed procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 0 0 409500 846652 27732000 28631 585 766 6 1 83 10 1 0 0 409328 846652 27732000 0 0 1003 1442 3 1 97 0 /proc/slabinfo ext3_inode_cache 176198 17620081651 : tunables 54 278 : slabdata 35240 35240 0 dentry233054 233054208 191 : tunables 120 608 : slabdata 12266 12266 0 buffer_head 228303 228327104 371 : tunables 120 608 : slabdata 6171 6171 0 run OpenOffice procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 1 0 0 403664 847056 27746000 23526 577 766 6 1 85 8 0 0 0 403656 847056 27746000 0 0 1003 1385 5 0 96 0 0 0 0 403888 847056 27746000 0 0 1237 1968 3 1 96 0 8< 0 0 0 400708 847088 27762000 0 0 1058 1259 4 0 95 0 0 0 0 400584 847088 27762000 0 0 1246 1647 7 1 93 0 1 1 0 389796 847164 28410000 6528 116 1215 2663 10 4 71 14 8< 0 0 0 307000 847464 361
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 21:32:08 Alexandre Oliva wrote: > On Jun 14, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > > They let you have the code and make changes to it, > > Not to the software installed in the device. So now you want access to all the software that is installed in their device? Could you explain that please? You do have access to the GPL code that they used. If you buy one of Google's Search Appliance, are you expecting to allow you to make changes to the software that is installed on that device? > > What they do is like an author A who distributes a program to user B > under a non-Free Software license, and to user C under a Free Software > license. > > C passes the program on to B under the same license. Now B has two > copies of the program. One is free, the other is not. > > Except that TiVO had no right to distribute the program under non-Free > terms in the first place, because it was not the author, and the > license it had explicitly said it couldn't impose further > restrictions. Reread what you wrote here and see the complete lack of logic in your argument. Author A are Linux developers who distribute their software under GPL 2, TiVO gets the software under the same license and distributes it to their end users. They then make the all the changes to the Linux Kernel available to their end users under the same terms that they got from the Linux kernel developers. What freedom did they take away? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 21:55:09 Alexandre Oliva wrote: > On Jun 14, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Thu, 14 Jun 2007, Diego Calleja wrote: > >> And the FSF is trying to control the design and licensing of > >> hardware throught the influence of their software. > > It's not. It's only working to ensure recipients of the Free Software > can modify and share the software. ^ Exactly what has been said to you the whole time, but you still refuse to accept that. If Linus develops and runs his code on a PowerPC and I struggle to install the code that he has released for me to modify and share on a PowerPC (maybe because I'm an idiot). Should I create a license with a Linusation term, because he is evil he runs his code on a PowerPC and I can't? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 02:55:52 Alexandre Oliva wrote: > On Jun 13, 2007, Bongani Hlope <[EMAIL PROTECTED]> wrote: > > On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote: > >> if you distribute copies of such a program, [...] > >> you must give the recipients all the rights that you have > >> > >> So, TiVo includes a copy of Linux in its DVR. > > > > And they give you the same right that they had, which is obtain free > > software that you can modify and redistribute. There's nothing in there > > that says they should give you the tools they used after they received > > the software, which is what you seem to be looking for. > > Can they modify the software in their device? > > Do they pass this right on? > > >> TiVo retains the right to modify that copy of Linux as it sees fit. > >> > >> It doesn't give the recipients the same right. > > > > It does, can't you modify their kernel source? > > It's not the kernel source. That's not where the TiVo anti-tampering > machinery blocks modifications. > > It's about that copy of the kernel that ships in the device in object > code. That's the one that TiVo customers ought to be entitled to > modify, if TiVo can modify it itself. > > > Where does it say you should be able to run you modifications on the > > same hardware? > > Where it says that you should pass on all the rights that you have. > > While TiVo retains the ability to replace, upgrade, fix, break or make > any other change in the GPLed software in the device, it ought to pass > it on to its customers. So according to your logic, I can go to Sharp's website and download the GPL source code for their Zaurus. But I don't own a Sharp Zaurus; to keep with your interpretation of the spirit of GPL, they have to give me a Zaurus so that I can run my modifications on the same hardware? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Thursday 14 June 2007 01:49:23 Alexandre Oliva wrote: > On Jun 13, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > The fact is, Tivo didn't take those rights away from you, yet the FSF > > says that what Tivo did was "against the spirit". That's *bullshit*. > > Oh, good, let's take this one. > > if you distribute copies of such a program, [...] > you must give the recipients all the rights that you have > > So, TiVo includes a copy of Linux in its DVR. > And they give you the same right that they had, which is obtain free software that you can modify and redistribute. There's nothing in there that says they should give you the tools they used after they received the software, which is what you seem to be looking for. > TiVo retains the right to modify that copy of Linux as it sees fit. > > It doesn't give the recipients the same right. > It does, can't you modify their kernel source? Where does it say you should be able to run you modifications on the same hardware? > Oops. > > Sounds like a violation of the spirit to me. > > Sounds like plugging this hole would retain the same spirit. The only fear that I have with the whole Tivo saga, is that companies like Dell can use the same thing to say: "Our hardware will only run Company's X distribution of Linux". Do we just hope users won't buy those Dell machines, or do you modify your software license to force Dell to allow custom distributions to run on their machines? Then where do we draw the line of "Software Licenses". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use C++ in kernel module?
On Friday 30 March 2007 05:49:14 Jan Engelhardt wrote: > On Mar 30 2007 11:37, Conke Hu wrote: > > Is it possible to use C++ in linux kernel module? how? > > I've tested but failed, there is an unknown symbol in the .o file from > > c++ source code. > > You answered it yourself. Linux does not have a C++ runtime. > It is possible to use a very limited set of C++ features, usually not > worth the fight. > > > Jan Do the "C++ kernel modules" crowd actually know C++? If they knew how C++ was designed, they would know that it requires some runtime support, which will stop them from asking this question over and over again. I'm begining to think that most of these questions are asked by people who think OO programing should used in the kernel (which is already done anyway) -- A log may float in a river, but that does not make it a crocodile. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad page state on AMD Opteron Dual System with kernel 2.6.13-rc6-git13
On Monday 29 August 2005 12:28 pm, you wrote: > Hi, > 8< > > Update, with stable 2.6.13. I get nearly the same behavior. > I haven't tried 2.6.13 yet (still downloading), could you first try this (with yor last working kernel, since you seem to have a problem with 2.6.13) echo 0 > /proc/sys/kernel/randomize_va_space If this "hides" the problems for you, please take a look at this bug report, and add your details: http://bugzilla.kernel.org/show_bug.cgi?id=4851 Regards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Tracking a bug in x86-64
On Wednesday 06 July 2005 08:34 am, Arjan van de Ven wrote:
> On Tue, 2005-07-05 at 14:12 -0700, Andrew Morton wrote:
> > Bongani Hlope <[EMAIL PROTECTED]> wrote:
> > >
> > > I haven't tested 2.6.12.2 but the problem was introduced around
> > > 2.6.11-mm1 and
> > > found its way to 2.6.12-rcX. First try to run the following command
> > > (this works for me)
> > > echo 0 > /proc/sys/kernel/randomize_va_space
> > > I got an email from Juan Gallego (cc'd), he says that command does not
> > > work for him though.
> > >
> > > Andrew,
> > > Should I log this on the kernel's bugzilla?
> >
> > Yes please. This is a tough one, and having one place to go to for the
> > info would be useful.
>
> key for this one is to make sure we separate the cases carefully, and
> not end up with one big bucket of "something broke" that has a gazilion
> different and unrelated causes.
> For the cases where a vm layout thing is suspected of causing the
> breakage we also really need a /proc//maps *at the time of the
> breakage* realistically for doing any kind of diagnostics.
>
The problem is, it is hard to get the /proc//maps file because the crashes
are just random.
If I set /proc/sys/kernel/randomize_va_space back to 1, and do a make -j4 on
the kernel source.
gcc will start to segfault or cause protection errors. I added a printk in the
randomize_stack_top function
just to print the pid and the random_variable (yes it is silly but...), the
problem went away.
I tried to capture the /proc//maps for the broken apps using the code
below (it captures some, but it is brain dead),
but the problem goes away. I'll try to write a bash script that does the same
and test.
#include
#include
#include
#include
#include
#include
using namespace std;
int main(int argc, char** argv) {
pid_t child;
child = fork();
if(child == 0) {
execvp("/usr/bin/g++", argv);
}
else if (child > 0) {
char* name = new char[256];
sprintf(name,"/proc/%ld/maps", child);
ifstream in(name);
delete[] name;
ofstream out("/home/bongani/log/procs.txt", ofstream::app);
name = new char[4096];
out<<""<<"\n";
out<<"g++("<http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Tracking a bug in x86-64
On Tuesday 05 July 2005 10:36 am, Sven Rudolph wrote: > Bongani Hlope <[EMAIL PROTECTED]> writes: > 8< > > Hi Linus > > > > I just tested, 2.6.12-rc6 minus > > randomisation-top-of-stack-randomization.patch Works For Me (tm) > > Sorry, I didn't follow the original discussion: Is this problem > expected to be solved in 2.6.12.2? Is it solved for you? > > (I get similiar problems in 2.6.12.2, and I am uns ure know how to > proceed.) > > Sven Hi Sven I haven't tested 2.6.12.2 but the problem was introduced around 2.6.11-mm1 and found its way to 2.6.12-rcX. First try to run the following command (this works for me) echo 0 > /proc/sys/kernel/randomize_va_space I got an email from Juan Gallego (cc'd), he says that command does not work for him though. Andrew, Should I log this on the kernel's bugzilla? Regards /etc/sysctl.conf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
