Test

Test

[saurabh chokshi]

Hi

-- 
REGARDS
Saurabh Chokshi

Re: test

[syzbot]

> #syz test

This crash does not have a reproducer. I cannot test it.

Re: [syzbot] [bpf?] KASAN: slab-out-of-bounds Write in __bpf_get_stackid

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    5b4c54ac49af bpf: Fix various typos in verifier.c comments
git tree:       bpf-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=17441782580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=934611ae034ab218
dashboard link: https://syzkaller.appspot.com/bug?extid=c9b724fbb41cf2538b7b
compiler:       Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16f294a2580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14349034580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5a5cfac28d08/disk-5b4c54ac.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/bb5b9f9f1b33/vmlinux-5b4c54ac.xz
kernel image: https://storage.googleapis.com/syzbot-assets/14b928da2760/bzImage-5b4c54ac.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c9b724fbb41cf2538b7b@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: slab-out-of-bounds in __bpf_get_stackid+0x677/0xcf0 kernel/bpf/stackmap.c:265
Write of size 8 at addr ffff8880439aa258 by task syz-executor265/6114

CPU: 1 UID: 0 PID: 6114 Comm: syz-executor265 Not tainted 6.16.0-rc6-syzkaller-g5b4c54ac49af #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
Call Trace:
 <IRQ>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x230 mm/kasan/report.c:480
 kasan_report+0x118/0x150 mm/kasan/report.c:593
 __bpf_get_stackid+0x677/0xcf0 kernel/bpf/stackmap.c:265
 ____bpf_get_stackid_raw_tp kernel/trace/bpf_trace.c:1810 [inline]
 bpf_get_stackid_raw_tp+0x196/0x210 kernel/trace/bpf_trace.c:1799
 bpf_prog_b724608cae728045+0x27/0x2f
 bpf_dispatcher_nop_func include/linux/bpf.h:1322 [inline]
 __bpf_prog_run include/linux/filter.h:718 [inline]
 bpf_prog_run include/linux/filter.h:725 [inline]
 __bpf_trace_run kernel/trace/bpf_trace.c:2257 [inline]
 bpf_trace_run2+0x284/0x4b0 kernel/trace/bpf_trace.c:2298
 __do_trace_kfree include/trace/events/kmem.h:94 [inline]
 trace_kfree include/trace/events/kmem.h:94 [inline]
 kfree+0x3a0/0x440 mm/slub.c:4829
 slab_free_after_rcu_debug+0x60/0x2a0 mm/slub.c:4680
 rcu_do_batch kernel/rcu/tree.c:2576 [inline]
 rcu_core+0xca8/0x1710 kernel/rcu/tree.c:2832
 handle_softirqs+0x283/0x870 kernel/softirq.c:579
 __do_softirq kernel/softirq.c:613 [inline]
 invoke_softirq kernel/softirq.c:453 [inline]
 __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0010:xas_load+0xd9/0x5b0 lib/xarray.c:244
Code: 42 0f b6 04 28 84 c0 0f 85 3a 04 00 00 49 8d 5e fe 48 8b 44 24 08 0f b6 28 48 89 d8 48 c1 e8 03 48 89 44 24 20 42 0f b6 04 28 <84> c0 0f 85 34 04 00 00 44 0f b6 23 44 0f b6 fd 44 89 ff 44 89 e6
RSP: 0000:ffffc9000459f898 EFLAGS: 00000a02
RAX: 0000000000000000 RBX: ffff888025438840 RCX: ffff88807c050000
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000002
RBP: 0000000000000000 R08: ffff88807c050000 R09: 0000000000000002
R10: 0000000000000003 R11: 0000000000000000 R12: ffffc9000459fb32
R13: dffffc0000000000 R14: ffff888025438842 R15: 0000000000000002
 xas_find+0x157/0x990 lib/xarray.c:1406
 next_uptodate_folio+0x32/0x5d0 mm/filemap.c:3562
 filemap_map_pages+0x21f/0x1740 mm/filemap.c:3714
 do_fault_around mm/memory.c:5548 [inline]
 do_read_fault mm/memory.c:5581 [inline]
 do_fault mm/memory.c:5724 [inline]
 do_pte_missing mm/memory.c:4251 [inline]
 handle_pte_fault mm/memory.c:6069 [inline]
 __handle_mm_fault+0x3687/0x5620 mm/memory.c:6212
 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6381
 do_user_addr_fault+0xa81/0x1390 arch/x86/mm/fault.c:1336
 handle_page_fault arch/x86/mm/fault.c:1476 [inline]
 exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0033:0x7f3d52e29438
Code: Unable to access opcode bytes at 0x7f3d52e2940e.
RSP: 002b:00007fff46c399c8 EFLAGS: 00010206
RAX: 00007f3d52e59ad8 RBX: 0000000000000000 RCX: 0000000000000004
RDX: 00007f3d52e5ad00 RSI: 0000000000000000 RDI: 00007f3d52e59ad8
RBP: 00007f3d52e58118 R08: 00007fff46c39a3c R09: 00007fff46c39a3c
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3d52e5ace8
R13: 0000000000000000 R14: 00007f3d52e5ad00 R15: 00007f3d52db0290
 </TASK>

Allocated by task 6114:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4328 [inline]
 __kmalloc_node_noprof+0x276/0x4e0 mm/slub.c:4334
 kmalloc_node_noprof include/linux/slab.h:932 [inline]
 __bpf_map_area_alloc kernel/bpf/syscall.c:391 [inline]
 bpf_map_area_alloc+0x64/0x180 kernel/bpf/syscall.c:404
 prealloc_elems_and_freelist+0x86/0x1d0 kernel/bpf/stackmap.c:51
 stack_map_alloc+0x33f/0x4c0 kernel/bpf/stackmap.c:114
 map_create+0xaa0/0x1310 kernel/bpf/syscall.c:1477
 __sys_bpf+0x60f/0x870 kernel/bpf/syscall.c:6004
 __do_sys_bpf kernel/bpf/syscall.c:6132 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:6130 [inline]
 __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6130
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff8880439aa000
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 24 bytes to the right of
 allocated 576-byte region [ffff8880439aa000, ffff8880439aa240)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x439a8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801a441dc0 0000000000000000 dead000000000001
raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88801a441dc0 0000000000000000 dead000000000001
head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 00fff00000000003 ffffea00010e6a01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5514, tgid 5514 (dhcpcd), ts 48384102667, free_ts 48383277611
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1704
 prep_new_page mm/page_alloc.c:1712 [inline]
 get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3669
 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:4959
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2419
 alloc_slab_page mm/slub.c:2451 [inline]
 allocate_slab+0x8a/0x3b0 mm/slub.c:2619
 new_slab mm/slub.c:2673 [inline]
 ___slab_alloc+0xbfc/0x1480 mm/slub.c:3859
 __slab_alloc mm/slub.c:3949 [inline]
 __slab_alloc_node mm/slub.c:4024 [inline]
 slab_alloc_node mm/slub.c:4185 [inline]
 __do_kmalloc_node mm/slub.c:4327 [inline]
 __kmalloc_noprof+0x305/0x4f0 mm/slub.c:4340
 kmalloc_noprof include/linux/slab.h:909 [inline]
 load_elf_phdrs fs/binfmt_elf.c:525 [inline]
 load_elf_binary+0x2cd/0x2790 fs/binfmt_elf.c:854
 search_binary_handler fs/exec.c:1670 [inline]
 exec_binprm fs/exec.c:1702 [inline]
 bprm_execve+0x999/0x1450 fs/exec.c:1754
 do_execveat_common+0x510/0x6a0 fs/exec.c:1860
 do_execve fs/exec.c:1934 [inline]
 __do_sys_execve fs/exec.c:2010 [inline]
 __se_sys_execve fs/exec.c:2005 [inline]
 __x64_sys_execve+0x94/0xb0 fs/exec.c:2005
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5514 tgid 5514 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1248 [inline]
 __free_frozen_pages+0xc71/0xe70 mm/page_alloc.c:2706
 discard_slab mm/slub.c:2717 [inline]
 __put_partials+0x161/0x1c0 mm/slub.c:3186
 put_cpu_partial+0x17c/0x250 mm/slub.c:3261
 __slab_free+0x2f7/0x400 mm/slub.c:4513
 qlink_free mm/kasan/quarantine.c:163 [inline]
 qlist_free_all+0x97/0x140 mm/kasan/quarantine.c:179
 kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
 __kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:329
 kasan_slab_alloc include/linux/kasan.h:250 [inline]
 slab_post_alloc_hook mm/slub.c:4148 [inline]
 slab_alloc_node mm/slub.c:4197 [inline]
 __do_kmalloc_node mm/slub.c:4327 [inline]
 __kmalloc_noprof+0x224/0x4f0 mm/slub.c:4340
 kmalloc_noprof include/linux/slab.h:909 [inline]
 tomoyo_add_entry security/tomoyo/common.c:2132 [inline]
 tomoyo_supervisor+0xbd5/0x1480 security/tomoyo/common.c:2204
 tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
 tomoyo_env_perm+0x149/0x1e0 security/tomoyo/environ.c:63
 tomoyo_environ security/tomoyo/domain.c:672 [inline]
 tomoyo_find_next_domain+0x15cf/0x1aa0 security/tomoyo/domain.c:888
 tomoyo_bprm_check_security+0x11c/0x180 security/tomoyo/tomoyo.c:102
 security_bprm_check+0x89/0x270 security/security.c:1302
 search_binary_handler fs/exec.c:1660 [inline]
 exec_binprm fs/exec.c:1702 [inline]
 bprm_execve+0x8ee/0x1450 fs/exec.c:1754
 do_execveat_common+0x510/0x6a0 fs/exec.c:1860
 do_execve fs/exec.c:1934 [inline]
 __do_sys_execve fs/exec.c:2010 [inline]
 __se_sys_execve fs/exec.c:2005 [inline]
 __x64_sys_execve+0x94/0xb0 fs/exec.c:2005

Memory state around the buggy address:
 ffff8880439aa100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff8880439aa180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8880439aa200: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
                                                    ^
 ffff8880439aa280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8880439aa300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
----------------
Code disassembly (best guess):
   0:	42 0f b6 04 28       	movzbl (%rax,%r13,1),%eax
   5:	84 c0                	test   %al,%al
   7:	0f 85 3a 04 00 00    	jne    0x447
   d:	49 8d 5e fe          	lea    -0x2(%r14),%rbx
  11:	48 8b 44 24 08       	mov    0x8(%rsp),%rax
  16:	0f b6 28             	movzbl (%rax),%ebp
  19:	48 89 d8             	mov    %rbx,%rax
  1c:	48 c1 e8 03          	shr    $0x3,%rax
  20:	48 89 44 24 20       	mov    %rax,0x20(%rsp)
  25:	42 0f b6 04 28       	movzbl (%rax,%r13,1),%eax
* 2a:	84 c0                	test   %al,%al <-- trapping instruction
  2c:	0f 85 34 04 00 00    	jne    0x466
  32:	44 0f b6 23          	movzbl (%rbx),%r12d
  36:	44 0f b6 fd          	movzbl %bpl,%r15d
  3a:	44 89 ff             	mov    %r15d,%edi
  3d:	44 89 e6             	mov    %r12d,%esi


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

test

[Arnaud lecomte]

#syz test

diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 3615c06b7dfa..c0ee51db8eed 100644
--- a/kernel/bpf/stackmap.c

 BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
           u64, flags)
 {
-       u32 max_depth = map->value_size / stack_map_data_size(map);
-       u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
+       u32 elem_size = stack_map_data_size(map);
        bool user = flags & BPF_F_USER_STACK;
        struct perf_callchain_entry *trace;
        bool kernel = !user;
+       u32 max_depth;

        if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
                               BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
                return -EINVAL;

-       max_depth += skip;
-       if (max_depth > sysctl_perf_event_max_stack)
-               max_depth = sysctl_perf_event_max_stack;
-
+       max_depth = stack_map_calculate_max_depth(map->value_size, elem_size, flags);
        trace = get_perf_callchain(regs, 0, kernel, user, max_depth,
                                   false, false);

@@ -371,15 +391,11 @@ BPF_CALL_3(bpf_get_stackid_pe, struct bpf_perf_event_data_kern *, ctx,
                return -EFAULT;

        nr_kernel = count_kernel_ip(trace);
+       __u64 nr = trace->nr; /* save original */

        if (kernel) {
-               __u64 nr = trace->nr;
-
                trace->nr = nr_kernel;
                ret = __bpf_get_stackid(map, trace, flags);
-
-               /* restore nr */
-               trace->nr = nr;
        } else { /* user */
                u64 skip = flags & BPF_F_SKIP_FIELD_MASK;

@@ -390,6 +406,10 @@ BPF_CALL_3(bpf_get_stackid_pe, struct bpf_perf_event_data_kern *, ctx,
                flags = (flags & ~BPF_F_SKIP_FIELD_MASK) | skip;
                ret = __bpf_get_stackid(map, trace, flags);
        }
+
+       /* restore nr */
+       trace->nr = nr;
+
        return ret;
 }

@@ -406,7 +426,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                            struct perf_callchain_entry *trace_in,
                            void *buf, u32 size, u64 flags, bool may_fault)
 {
-       u32 trace_nr, copy_len, elem_size, num_elem, max_depth;
+       u32 trace_nr, copy_len, elem_size, max_depth;
        bool user_build_id = flags & BPF_F_USER_BUILD_ID;
        bool crosstask = task && task != current;
        u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
@@ -438,21 +458,20 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
                goto clear;
        }

-       num_elem = size / elem_size;
-       max_depth = num_elem + skip;
-       if (sysctl_perf_event_max_stack < max_depth)
-               max_depth = sysctl_perf_event_max_stack;
+       max_depth = stack_map_calculate_max_depth(size, elem_size, flags);

        if (may_fault)
                rcu_read_lock(); /* need RCU for perf's callchain below */

-       if (trace_in)
+       if (trace_in) {
                trace = trace_in;
-       else if (kernel && task)
+               trace->nr = min_t(u32, trace->nr, max_depth);
+       } else if (kernel && task) {
                trace = get_callchain_entry_for_task(task, max_depth);
-       else
+       } else {
                trace = get_perf_callchain(regs, 0, kernel, user, max_depth,
                                           crosstask, false);
+       }

        if (unlikely(!trace) || trace->nr < skip) {
                if (may_fault)
@@ -461,7 +480,6 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
        }

        trace_nr = trace->nr - skip;
-       trace_nr = (trace_nr <= num_elem) ? trace_nr : num_elem;
        copy_len = trace_nr * elem_size;

        ips = trace->ip + skip;
--
2.47.3

Test

[Arnaud lecomte]

#syz test: git@github.com:ArnaudLcm/linux.git bpf-slab-fix

Test

[Arnaud lecomte]

#syz test: https://github.com/ArnaudLcm/linux.git bpf-slab-fix

Re: Test

[syzbot]

> #syz test:

This crash does not have a reproducer. I cannot test it.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Re: test

[syzbot]

> #syz test:

This crash does not have a reproducer. I cannot test it.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Re: Test

[syzbot]

> #syz test:�https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

unknown command "test:\xa0https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"

test

[jhrhhao]

test

Test

[Verma, Achal]

Testing as my previous reply not saved in archive.

On 1/17/2023 3:31 PM, Achal Verma wrote:
> Test-email
> 

[PATCH] taprio: Set the value of picos_per_byte before fill sched_entry

[jianghaoran]

If the value of picos_per_byte is set after fill sched_entry,
as a result, the min_duration calculated by length_to_duration is 0,
and the validity of the input interval cannot be judged,
too small intervals couldn't allow any packet to be transmitted.
It will appear like commit b5b73b26b3ca ("taprio:
Fix allowing too small intervals") described problem.
Here is a further modification of this problem.

example:

tc qdisc replace dev enp5s0f0 parent root handle 100 taprio \
              num_tc 3 \
              map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
              queues 1@0 1@1 2@2 \
              base-time  1528743495910289987 \
              sched-entry S 01 9 \
	      sched-entry S 02 9 \
	      sched-entry S 04 9 \
              clockid CLOCK_TAI

Signed-off-by: jianghaoran <jianghaoran@kylinos.cn>
---
 net/sched/sch_taprio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 86675a79da1e..d95ec2250f24 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -1507,6 +1507,8 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt,
 		goto free_sched;
 	}
 
+	taprio_set_picos_per_byte(dev, q);
+
 	err = parse_taprio_schedule(q, tb, new_admin, extack);
 	if (err < 0)
 		goto free_sched;
@@ -1521,8 +1523,6 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt,
 	if (err < 0)
 		goto free_sched;
 
-	taprio_set_picos_per_byte(dev, q);
-
 	if (mqprio) {
 		err = netdev_set_num_tc(dev, mqprio->num_tc);
 		if (err)
-- 
2.25.1

Re: [PATCH] taprio: Set the value of picos_per_byte before fill sched_entry

[Jakub Kicinski]

On Wed, 28 Sep 2022 14:58:30 +0800 jianghaoran wrote:
> If the value of picos_per_byte is set after fill sched_entry,
> as a result, the min_duration calculated by length_to_duration is 0,
> and the validity of the input interval cannot be judged,
> too small intervals couldn't allow any packet to be transmitted.

Meaning an invalid configuration is accepted but no packets
can ever be transmitted?  Could you make the user-visible 
issue clearer?

> It will appear like commit b5b73b26b3ca ("taprio:
> Fix allowing too small intervals") described problem.
> Here is a further modification of this problem.
> 
> example:

Here as well it seems worthwhile to mention what this is an example of.
e.g. "example configuration which will not be able to transmit packets"

> tc qdisc replace dev enp5s0f0 parent root handle 100 taprio \
>               num_tc 3 \
>               map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
>               queues 1@0 1@1 2@2 \
>               base-time  1528743495910289987 \
>               sched-entry S 01 9 \
> 	      sched-entry S 02 9 \
> 	      sched-entry S 04 9 \
>               clockid CLOCK_TAI

Please add a Fixes tag pointing to the first commit where the issue was
present, and CC Vladimir Oltean <vladimir.oltean@nxp.com> on the next
version.

test

[jianghaoran]

test

[Robin01.Guo]

-- 
Robin01.Guo <Robin01.Guo@outlook.com>

test

[owen]

test
test

test

[owen]

test
test

test

[Abbas Maheryar]

this is a test

test

[dzp]

test

Test

[Turritopsis Dohrnii Teo En Ming]

Test

TEST

[Jeffrin Jose T]

This is  test mail

test

[Damian Tometzki]

test

test

[SHANNAN Syrjala]

test

test

[test]

test

test

[xiakaixu]

Sorry for noise!
-- 
Regards
Kaixu Xia

test

[Lucius Rizzo]

please ignore. 

test

[xiaofeng.yan]

test

test

[zhouziyan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 172 bytes --]

 		 	   		  ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

test

[Sabri Altunbas]

test

[Carl-Valentin Schmitt]

this e-mail is a test.

want to check if I am already subscribed to vger.kernel.org

Val.

TEST

[Han Cheng]

Sorry， just a test...

test

[Peiyong Feng]

test

test

[Wu, Xia]

test

[Vasiliy G Tolstov]

test

test

[Wu, Xia]

test

[Steven Xu]

test

test

[Yeoh, JoyceX]

Testing 

test

[Charmaine Brugnoli]

test

test

[kulvan811]

test mail 

test

[Pranith Kumar]

Signed-off-by: D Pranith Kumar <bobby.prani@gmail.com>

diff --git a/drivers/staging/otus/ioctl.c b/drivers/staging/otus/ioctl.c
index ce04218..5e8bd94 100644
--- a/drivers/staging/otus/ioctl.c
+++ b/drivers/staging/otus/ioctl.c
@@ -2045,6 +2045,7 @@ int usbdrv_wpa_ioctl(struct net_device *dev, 
struct athr_wlan_param *zdparm)
    struct zsKeyInfo keyInfo;
    struct usbdrv_private *macp = dev->ml_priv;
    u16_t vapId = 0;
+    int ii;

    /* zmw_get_wlan_dev(dev); */

@@ -2168,7 +2169,6 @@ int usbdrv_wpa_ioctl(struct net_device *dev, 
struct athr_wlan_param *zdparm)
        /* DUMP key context */
        /* #ifdef WPA_DEBUG */
        if (keyInfo.keyLength > 0) {
-            int ii;
            printk(KERN_WARNING
                        "Otus: Key Context:\n");
            for (ii = 0; ii < keyInfo.keyLength; ) {
@@ -2266,7 +2266,6 @@ int usbdrv_wpa_ioctl(struct net_device *dev, 
struct athr_wlan_param *zdparm)
        /* zfiWlanSetWpaIe(dev, zdparm->u.generic_elem.data,
        * zdparm->u.generic_elem.len);
        */
-        int ii;
        u8_t len = zdparm->u.generic_elem.len;
        u8_t *wpaie = (u8_t *)zdparm->u.generic_elem.data;

@@ -2401,7 +2400,7 @@ int usbdrv_ioctl(struct net_device *dev, struct 
ifreq *ifr, int cmd)
    struct athr_wlan_param zdparm;
    struct usbdrv_private *macp = dev->ml_priv;

-    int err = 0;
+    int err = 0, val = 0;
    int changed = 0;

    /* regp = macp->regp; */
@@ -2445,7 +2444,7 @@ int usbdrv_ioctl(struct net_device *dev, struct 
ifreq *ifr, int cmd)
            err = -EPERM;
            break;
        }
-        int val = *((int *) wrq->u.name);
+       val = *((int *) wrq->u.name);
        if ((val < 0) || (val > 2)) {
            err = -EINVAL;
            break;
diff --git a/drivers/staging/rt2860/common/ba_action.c 
b/drivers/staging/rt2860/common/ba_action.c
index 591d1e2..befd8bd 100644
--- a/drivers/staging/rt2860/common/ba_action.c
+++ b/drivers/staging/rt2860/common/ba_action.c
@@ -1512,7 +1512,7 @@ void 
convert_reordering_packet_to_preAMSDU_or_802_3_packet(
    RTPKT_TO_OSPKT(pRxPkt)->dev = get_netdev_from_bssid(pAd, 
FromWhichBSSID);
    RTPKT_TO_OSPKT(pRxPkt)->data = pRxBlk->pData;
    RTPKT_TO_OSPKT(pRxPkt)->len = pRxBlk->DataSize;
-    RTPKT_TO_OSPKT(pRxPkt)->tail = RTPKT_TO_OSPKT(pRxPkt)->data + 
RTPKT_TO_OSPKT(pRxPkt)->len;
+    RTPKT_TO_OSPKT(pRxPkt)->tail = (UCHAR *) 
(RTPKT_TO_OSPKT(pRxPkt)->data + RTPKT_TO_OSPKT(pRxPkt)->len);

    //
    // copy 802.3 header, if necessary
diff --git a/drivers/staging/rt2860/rt_linux.c 
b/drivers/staging/rt2860/rt_linux.c
index f3c128c..36ffb97 100644
--- a/drivers/staging/rt2860/rt_linux.c
+++ b/drivers/staging/rt2860/rt_linux.c
@@ -607,7 +607,7 @@ PNDIS_PACKET ClonePacket(
        pClonedPkt->dev = pRxPkt->dev;
        pClonedPkt->data = pData;
        pClonedPkt->len = DataSize;
-        pClonedPkt->tail = pClonedPkt->data + pClonedPkt->len;
+       pClonedPkt->tail = (UCHAR *) (pClonedPkt->data + pClonedPkt->len);
        ASSERT(DataSize < 1530);
    }
    return pClonedPkt;
@@ -629,7 +629,7 @@ void  update_os_packet_info(
    pOSPkt->dev = get_netdev_from_bssid(pAd, FromWhichBSSID);
    pOSPkt->data = pRxBlk->pData;
    pOSPkt->len = pRxBlk->DataSize;
-    pOSPkt->tail = pOSPkt->data + pOSPkt->len;
+    pOSPkt->tail = (UCHAR *) (pOSPkt->data + pOSPkt->len);
}


@@ -649,7 +649,7 @@ void wlan_802_11_to_802_3_packet(
    pOSPkt->dev = get_netdev_from_bssid(pAd, FromWhichBSSID);
    pOSPkt->data = pRxBlk->pData;
    pOSPkt->len = pRxBlk->DataSize;
-    pOSPkt->tail = pOSPkt->data + pOSPkt->len;
+    pOSPkt->tail = (UCHAR *) (pOSPkt->data + pOSPkt->len);

    //
    // copy 802.3 header
diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 6f5d0bf..43bdd9d 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1872,7 +1872,7 @@ static int slic_card_download(struct adapter 
*adapter)
    __iomem struct slic_regs *slic_regs = adapter->slic_regs;
    u32 instruction;
    u32 baseaddress;
-    u32 failure;
+    /* u32 failure; */
    u32 i;
    u32 numsects = 0;
    u32 sectsize[3];
diff --git a/drivers/staging/sxg/sxg.c b/drivers/staging/sxg/sxg.c
index 076b3f7..30bbf76 100644
--- a/drivers/staging/sxg/sxg.c
+++ b/drivers/staging/sxg/sxg.c
@@ -2150,7 +2150,7 @@ void sxg_set_interrupt_aggregation(struct 
adapter_t *adapter)
static int sxg_entry_open(struct net_device *dev)
{
    struct adapter_t *adapter = (struct adapter_t *) netdev_priv(dev);
-    int status;
+    int status = STATUS_FAILURE;
    static int turn;
    int sxg_initial_rcv_data_buffers = SXG_INITIAL_RCV_DATA_BUFFERS;
    int i;

test

[promos]

test

Para anular su suscripción:
http://www.eysweb.com/mailinglist/subscription.php?list_id=1&op=leave&email_addr=linux-kernel%40vger.kernel.org

test

[promos]

test

Para anular su suscripción:
http://www.eysweb.com/mailinglist/subscription.php?list_id=1&op=leave&email_addr=linux-kernel%40vger.kernel.org

Test

[linux-os (Dick Johnson)]

Hmmm,
No list Email today. I can send Email to this account
from outside so the Email works.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.25.17 on an i686 machine (4786.81 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Test

[johnson_Michael4]

Hello,

My Name is Dr. Johnson Michael from Harlesden , working with Natwest Bank Corporation , North West London , England.I am contacting you for a transaction amounting to $12.5 belonging to one of our late customers who died with his family in the plane crash of Alaska Airlines Flight 261 on the 31st January 2000.

Due to the sensitivity and the confidentiality of this transaction,I am contrained to issue further details until your positive response is received.

Thank you for your time and attention. 

Best Regards 
 
Dr.Johnson Michael
+4407031977761

test

[Stephen Clark]

test - is the ml alive.

-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)

Re: test

[Jan Engelhardt]

On Jan 31 2008 11:32, Stephen Clark wrote:
>
> test - is the ml alive.
>

'tis ml be well alive; if ye don't get mails, check the spam filters
(high-volume list)

#include "test-rant.txt"

Test

[mchu]

Test

Test

[andrew.wbeelsoi]

testtt

test

[Phy Prabab]

test

Test

[Ismail Donmez]

Please ignore, vger-test seems accept mails but not linux-kernel.

Test

[rstevens2008]

Test

test

[Jiri Slaby]

just another-one-ignore

test

[Jiri Slaby]

just ignore

Re: test

[Michal Piotrowski]

Hi Jiri,

On 29/07/06, Jiri Slaby <jirislaby@gmail.com> wrote:
> just ignore

There is a simple vger test

"You can test email delivery between you, and VGER by sending an empty
test letter to: <autoanswer@vger.kernel.org>"
http://vger.kernel.org/majordomo-info.html

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: test

[Jiri Slaby]

Michal Piotrowski napsal(a):
> Hi Jiri,
> 
> On 29/07/06, Jiri Slaby <jirislaby@gmail.com> wrote:
>> just ignore
> 
> There is a simple vger test
> 
> "You can test email delivery between you, and VGER by sending an empty
> test letter to: <autoanswer@vger.kernel.org>"
> http://vger.kernel.org/majordomo-info.html

Wow, thnaks, sorry for the noise!

thanks,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Ethernet driver module compilation (8139too)

[Chava Leviatan]

Hello,

My Linux 2.4.18 machine has 2 ethernet interfaces: eepro100 and 8139too.

I need to put a minur changes (printk messages) into those drivers, which
are loaded as kernel modules .

I first changed the eepro then  compiled it seperatly (with
_DMODULE, -D__KERNEL and the correct path into
/lib/modules/.....) and everything worked well (was able to see my printing
through dmesg).

When I tried to change 8139too, it did not work -- not because of the code
change -- rather , I had some
problems in compiling this module.
When i rebooted the machine the interfaces wer not up, and when I did lsmod
8139too was not there.
I then tried to manually install it (insmod) and was promp with unresolved
external. I found out that
those unresolved belong to mii.o which was not loaded during the boot
process.
When I changed to the original 8139too.o (luckily I have saved it ...) the
machine is ok, mii.o
is loadede , and also 8139too.

I am sure the problem is in the way I compile this module , but i don't know
what is missing ?
I have browsed many Makefiles and could not tell what flags make the
8139too.o tell the boot that
it needs mii.o . The modules.dep file create during boot tme shows that
8139too depends on mii.o,
but from some reason mii.o is ot loaded.

Maybe I can not compile kernel modules seperatly, i.e., kernel modules that
are loaded during bot time ?

Obviosly i can do this procee manually: insmod mii, then 8139 and finally
bring the interface up.
But, i really need to know what went wrong there

Any help will be much appreciated

Chava Leviatan

Re: Ethernet driver module compilation (8139too)

[Brian F. G. Bidulock]

Chava,

On Mon, 29 May 2006, Chava Leviatan wrote:
> I then tried to manually install it (insmod) and was promp with unresolved
> external. I found out that
> those unresolved belong to mii.o which was not loaded during the boot
> process.

Did you reboot the machine?  Did you do depmod -ae?

Which symbols?  What did the error message say exactly...  What is the
output of depmod -ae with the module installed?

--brian

Re: Ethernet driver module compilation (8139too)

[Chava Leviatan]

Hi Brian,

I did reboot the machine, and saw that during boot time there is a call to 
depmod.
I did depmod -ae as you've requested, and here are the results:
  [root@NettGain root]# depmod -ae >chav.dat
depmod: /lib/modules/2.4.18-3/kernel/drivers/net/makefile.8139 is not an ELF 
file
depmod: /lib/modules/2.4.18-3/kernel/drivers/net/makefile.eepro is not an 
ELF file
depmod: *** Unresolved symbols in 
/lib/modules/2.4.18-3/kernel/drivers/net/8139too.o
depmod:         __netdev_watchdog_up
depmod:         flush_signals
depmod:         eth_type_trans
depmod:         mii_ethtool_sset
depmod:         __kfree_skb
depmod:         alloc_skb
depmod:         pci_register_driver
depmod:         mii_link_ok
depmod:         pci_free_consistent
depmod:         pci_enable_device
depmod:         pci_read_config_byte
depmod:         alloc_etherdev
depmod:         mii_ethtool_gset
depmod:         reparent_to_init
depmod:         cpu_raise_softirq
depmod:         free_irq
depmod:         unregister_netdev
depmod:         kill_proc
depmod:         iounmap
depmod:         pci_alloc_consistent
depmod:         interruptible_sleep_on_timeout
depmod:         __ioremap
depmod:         pci_read_config_word
depmod:         skb_copy_and_csum_dev
depmod:         register_netdev
depmod:         kfree
depmod:         pci_release_regions
depmod:         wait_for_completion
depmod:         request_irq
depmod:         mii_nway_restart
depmod:         netif_rx
depmod:         pci_unregister_driver
depmod:         skb_over_panic
depmod:         pci_set_master
depmod:         do_BUG
depmod:         rtnl_unlock
depmod:         pci_write_config_word
depmod:         daemonize
depmod:         jiffies
depmod:         softnet_data
depmod:         rtnl_lock
depmod:         printk
depmod:         complete_and_exit
depmod:         kernel_thread
depmod:         __const_udelay
depmod:         pci_request_regions


Please note that if I manually insmod mii , then the insmod 8139too passes 
w/o problems .

Chava
----- Original Message ----- 
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: "Chava Leviatan" <chavale@actcom.net.il>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, May 29, 2006 10:13 AM
Subject: Re: Ethernet driver module compilation (8139too)


> Chava,
>
> On Mon, 29 May 2006, Chava Leviatan wrote:
>> I then tried to manually install it (insmod) and was promp with 
>> unresolved
>> external. I found out that
>> those unresolved belong to mii.o which was not loaded during the boot
>> process.
>
> Did you reboot the machine?  Did you do depmod -ae?
>
> Which symbols?  What did the error message say exactly...  What is the
> output of depmod -ae with the module installed?
>
> --brian
> 

Re: Ethernet driver module compilation (8139too)

[Brian F. G. Bidulock]

Chava,

On Mon, 29 May 2006, Chava Leviatan wrote:

> Hi Brian,
> 
> I did reboot the machine, and saw that during boot time there is a call to 
> depmod.
> I did depmod -ae as you've requested, and here are the results:
>   [root@NettGain root]# depmod -ae >chav.dat
> depmod: /lib/modules/2.4.18-3/kernel/drivers/net/makefile.8139 is not an ELF 
> file
> depmod: /lib/modules/2.4.18-3/kernel/drivers/net/makefile.eepro is not an 
> ELF file
> depmod: *** Unresolved symbols in 
> /lib/modules/2.4.18-3/kernel/drivers/net/8139too.o
> depmod:         __netdev_watchdog_up
> depmod:         flush_signals
...
...
> depmod:         mii_ethtool_gset
...
...
> 
> Please note that if I manually insmod mii , then the insmod 8139too passes 
> w/o problems .
> 

I don't see how it could with all those depmod errors.  Try doing
this:

 grep uregister_netdev /proc/ksyms

If you get something like this:

  c0194ef0 unregister_netdev_Rc45f34ea
  c01d5270 unregister_netdevice_notifier_Rfe769456
  c01d6ca0 unregister_netdevice_R52c1d940

then your kernel has versioned symbols.

In which case, you are probably missing

 -DMODVERSIONS -include linux/modversions.h

from your compile statement.

Hope that helps.

--brian

Re: Ethernet driver module compilation (8139too)

[Chava Leviatan]

Hi Brian ,

Thanks alot ! This exactly the line I was missing at my makefile !
Now it works ...


Chava
----- Original Message ----- 
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: "Chava Leviatan" <chavale@actcom.net.il>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, May 29, 2006 11:53 AM
Subject: Re: Ethernet driver module compilation (8139too)


> Chava,
>
> On Mon, 29 May 2006, Chava Leviatan wrote:
>
>> Hi Brian,
>>
>> I did reboot the machine, and saw that during boot time there is a call 
>> to
>> depmod.
>> I did depmod -ae as you've requested, and here are the results:
>>   [root@NettGain root]# depmod -ae >chav.dat
>> depmod: /lib/modules/2.4.18-3/kernel/drivers/net/makefile.8139 is not an 
>> ELF
>> file
>> depmod: /lib/modules/2.4.18-3/kernel/drivers/net/makefile.eepro is not an
>> ELF file
>> depmod: *** Unresolved symbols in
>> /lib/modules/2.4.18-3/kernel/drivers/net/8139too.o
>> depmod:         __netdev_watchdog_up
>> depmod:         flush_signals
> ...
> ...
>> depmod:         mii_ethtool_gset
> ...
> ...
>>
>> Please note that if I manually insmod mii , then the insmod 8139too 
>> passes
>> w/o problems .
>>
>
> I don't see how it could with all those depmod errors.  Try doing
> this:
>
> grep uregister_netdev /proc/ksyms
>
> If you get something like this:
>
>  c0194ef0 unregister_netdev_Rc45f34ea
>  c01d5270 unregister_netdevice_notifier_Rfe769456
>  c01d6ca0 unregister_netdevice_R52c1d940
>
> then your kernel has versioned symbols.
>
> In which case, you are probably missing
>
> -DMODVERSIONS -include linux/modversions.h
>
> from your compile statement.
>
> Hope that helps.
>
> --brian
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Ethernet driver module compilation (8139too)

[David Woodhouse]

On Mon, 2006-05-29 at 13:34 +0200, Chava Leviatan wrote:
> Thanks alot ! This exactly the line I was missing at my makefile !
> Now it works ... 

That should be done by the kernel makefile. Your real problem seems to
be that you were attempting to use your own makefile instead of the
kernel's.

-- 
dwmw2

test

[Suresh G]

test

test

[mark gross]

outlook sucks.

Re: test

[linux-os (Dick Johnson)]

On Wed, 26 Apr 2006, mark gross wrote:

> outlook sucks.
>

Now, if you'd only used Outlook-Express, I could send you something
that would fix it --for good!

Can't you smuggle in something that runs pine?

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: test

[Jan Engelhardt]

>> outlook sucks.
>>
>
>Now, if you'd only used Outlook-Express, I could send you something
>that would fix it --for good!
>
>Can't you smuggle in something that runs pine?
>
Pine for WIN32.


Jan Engelhardt
-- 

Re: test

[linux-os (Dick Johnson)]

On Thu, 27 Apr 2006, Jan Engelhardt wrote:

>>> outlook sucks.
>>>
>>
>> Now, if you'd only used Outlook-Express, I could send you something
>> that would fix it --for good!
>>
>> Can't you smuggle in something that runs pine?
>>
> Pine for WIN32.
>

Real people don't use WIN32 );... Except for getting notices from
the Human Resources Departments.

> Jan Engelhardt

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: test

[Jan Engelhardt]

>>> Now, if you'd only used Outlook-Express, I could send you something
>>> that would fix it --for good!
>>>
>>> Can't you smuggle in something that runs pine?
>>>
>> Pine for WIN32.
>
>Real people don't use WIN32 );... Except for getting notices from
>the Human Resources Departments.
>
Sometimes you are forced to use WIN32, and you can't do anything about.
In which case you should make it as comfortable as possible.


Jan Engelhardt
-- 

test

[Eric Moore]

test

test

[bjdouma]

Please don't respond, or I'll have to explain why this
is necessary. Thanks.
bjd

test

[bjd]

Please don't respond, or I'll have to explain why this
is necessary. Thanks.
bjd

test

[News system]

testppostginfg

test

[info]

.

Re: test

[Jesper Juhl]

On 9 Dec 2005 12:19:37 +0900, info@loveisover.com <info@loveisover.com> wrote:
>
> .

'Don't post "Just testing: Is the list working? I didn't get any mail
for a few days now".'

http://www.tux.org/lkml/#s3-15


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: test

[Alejandro Bonilla]

On Fri, 9 Dec 2005 11:21:37 +0100, Jesper Juhl wrote
> On 9 Dec 2005 12:19:37 +0900, info@loveisover.com 
> <info@loveisover.com> wrote:
> >
> > .
> 
> 'Don't post "Just testing: Is the list working? I didn't get any mail
> for a few days now".'
> 
> http://www.tux.org/lkml/#s3-15

One doesn't have to be a Rocket scientist to notice that the original email
was spam.

.Alejandro


> 
> --
> Jesper Juhl <jesper.juhl@gmail.com>
> Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please      http://www.expita.com/nomime.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in the body of a message to majordomo@vger.kernel.org More 
> majordomo info at  http://vger.kernel.org/majordomo-info.html Please 
> read the FAQ at  http://www.tux.org/lkml/


--
Open WebMail Project (http://openwebmail.org)

test

[info]

.

Re: test

[Felix Oxley]

Sorry, that was _not_ supposed to come to LKML. :-(

test

[DVE - Gabriele Brugnoni]

test2

test

[Erick]

Test

[Johnson, Richard]

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

test

[kwalarski]

test

Test

[Ivan Yosifov]

Test

[Ivan Yosifov]

Hi List !

test

[ziew]

this is a test.(feeding "non-ham" dogs).
if you want to help, please put this on your website somewhere:
<A HREF="mailto:eatshitanddie@pointblue.com.pl"></A>


--
Duke

Test

[Sean Fendt]

-- 
--Sean Fendt
kernel@sfendt.net

test

[lala]

Test

[test]

Dear ,

We are conducting a survey, and your response would be appreciated.

Here is a link to the survey:
http://www.surveymonkey.com/s.asp?A=44080039E8312

Thanks for your participation,

       Your Name
       
Please note: If do not wish to receive further emails from us, please click the link below, and you will be automatically removed from our mailing list.
http://www.surveymonkey.com/r.asp?A=44080039E8312



***Powered by SurveyMonkey.com***

test

[Miguel Bolanos]

test

[Fabiano Ramos]

test

[Ernst, Yehuda]

test
***********************************************************************************
Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@ndsisrael.com and destroy the original message.
***********************************************************************************

test

[Galimberti, Gustavo]

Test

[Green, Jeff]

 Test

test

[nick]

please ignore.

Test

[Christian Ludwig]

TEST

test

[Ronald Jerome]

test

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

test

[Galimberti, Gustavo]

test

[paul buenrostro]

test

_________________________________________________________________
Charla con tus amigos en línea mediante MSN Messenger: 
http://messenger.yupimsn.com/

RE: test

[Riley Williams]

Hi Paul.

 > test

As usual, it failed   8)

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.484 / Virus Database: 282 - Release Date: 27-May-2003

test

[paul buenrostro]

test

___________________________________________________
Todito Card, internet fácil y sin compromisos.
Todito Ilimitado, internet rápido, seguro y económico.

test

[Max Valdez]

Why my messages get to the list empty?? 

I'm using evolution, is it doing something??, is my SMTP server??

Thanks for any response
Max
-- 
Nunca ! Jamas !

Re: test

[Maciej Soltysiak]

> Why my messages get to the list empty??
They are not empty. I am replying to a non-empty message, aren't I ?

Regards,
Maciej

Re: 2.5.65-mm2

[Mike Galbraith]

At 11:17 PM 3/19/2003 +0000, Charles Baylis wrote:

>I'm getting quite a lot of audio skips with this one. 2.5.64-mm8 was the
>last one I tested and it was very good.
>
>2.5.64-mm8 works fine with pretty much any thud load I throw at it, but thud
>3 is enough to cause some skips with 2.5.65-mm2. Thud 5 causes serious
>starvation problems to the whole desktop.

My crude hack helped with thud and some others, but is b0rken for others.

         -Mike  

test

[panchi]

test mail

test

[Claudio Novaes Figueira]

this is a test.

_______________________________________________________________________
Busca Yahoo!
O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra.
http://br.busca.yahoo.com/

test

[Adrian Etchevarne]

test

[Claudio Novaes Figueira]

It's the test.

_______________________________________________________________________
Busca Yahoo!
O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra.
http://br.busca.yahoo.com/

test

[Rudmer van Dijk]

werken ze allemaal??

test

[Halil]

test msg. linux is super cool.
hi all.
-hd

test

[Vergoz Michael]

test

test

[hacker]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

test
>From - Wed Jul 18 13:13:13 2001
Return-path: <postmaster@server0021.freedom2surf.net>
Envelope-to: klages@online.de
Delivery-date: Wed, 18 Jul 2001 09:06:17 +0200

[-- Attachment #2: WebBeatZ_de - HIPHOP PROMOTION.htm.exe --]
[-- Type: application/x-msdownload, Size: 50688 bytes --]

test

[walairat kladmuk]

test

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

test

[Andrei Ivanov]

Am I still on this list ?
Didn't receive any message today... :(

Re: test

[Rik van Riel]

On Wed, 31 Jul 2002, Andrei Ivanov wrote:

> Am I still on this list ?
> Didn't receive any message today... :(

I guess it's better to ask majordomo@vger.kernel.org instead
of asking the list ;)

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

test

[louie miranda]

test

test

[Isaac Connor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8cCmLP9P4rM8SWB4RAqorAJsENBeALIUeDvHKwkeuH41gOx2s3gCfTLHR
ZYkArqP6YGRsrpyOF9TtK34=
=hN0M
-----END PGP SIGNATURE-----

test

[Justin Piszcz]

my mail server has been down, haven't gotten any messages from this
group.. testing

test

[T. A.]

test, not getting linux-kernel mail.

test

[Rajive Chittajallu]

fasdf

test

[Rajive Chittajallu]

fasfda

Test

[Hans-Peter Jansen]

my last two messages didn't show up in this list.
Would some kind soul replay on this. Thx.

Hans-Peter

test

[Rajiv Malik]

test!

sorry list, but messages were not coming to me.

test

[[A]ndy80]

-- 
   ~            Piccoli Software
  ° °	http://www.piccolisoftware.cjb.net
  /V\      piccolisoftware@pegacity.it
 // \\
/(   )\  [A]ndy80 on #bluvertigo e #pistoia
 ^`~'^  andy80@ptlug.org - http://www.ptlug.org

GPG Key: http://www.ptlug.org/andy80_key.asc

test

[David Rundle]

test

test

[hugang]

-- 
Best Regard!
礼！
----------------------------------------------------
hugang : 胡刚 	GNU/Linux User
email  : gang_hu@soul.com.cn linuxbest@soul.com.cn
Tel    : +861068425741/2/3/4
Web    : http://www.soul.com.cn

	Beijing Soul technology Co.Ltd.
	   北京众志和达科技有限公司
----------------------------------------------------

test

[david]

this is a test

Test

[Mark Klassen]

Test....

Test

[Rich Baum]

I haven't recieved any messages since Saturday.  I'm just checking to see if 
the list still works.

test

[John Heil]

mail test - ignore

-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

test

[Jiri Kroupa]

this is just the test - ignore it please


EMAIL.CZ - Vase posta je vzdy s Vami na  
http://www.email.cz

test

[Josh McKinney]

sory again

test

[Roger Larsson]

test

test

[Roger Larsson]

OK, you had to...

I have not seen any emails from linux-kernel for some days.
Even tried to resubscribe - Majordomo succeeded in sending me the Confirmation

But nothing...

So I have to try this...

/RogerL

(I am subscribed as roger.larsson@skelleftea.mail.telia.com)

-- 
Home page:
  none currently
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: test

[Ben Ford]

Roger Larsson wrote:

> OK, you had to...
>
> I have not seen any emails from linux-kernel for some days.
> Even tried to resubscribe - Majordomo succeeded in sending me the Confirmation
>
> But nothing...
>

I must be getting all yours then!!  Seriously, something's broke, I am getting
duplicates of *every* *freaking* lkml message!!

-b


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/