* RE: Failed to pass make on ia32
From: Ling, Xiaofeng @ 2005-07-19 1:09 UTC (permalink / raw)
To: Yu, Lifeng, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1346 bytes --]
I can build on my machine with 5812.
Try to use hg co -C
________________________________
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Yu, Lifeng
Sent: 2005?7?19? 08:54
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Failed to pass make on ia32
On lateset changeset 5812, We failed to pass make on ia32. Anyone met with the same problem?
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/root/work/hg/xen-src/xen/include -I/root/work/hg/xen-src/xen/include/asm-x86/mach-generic -I/root/work/hg/xen-src/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c vmx.c -o vmx.o
vmx.c: In function `vmx_vmexit_handler':
vmx.c:1667: error: syntax error before '<<' token
vmx.c:1679: error: syntax error before '==' token
vmx.c:1681:25: invalid suffix "zb2zg" on floating constant
make[3]: *** [vmx.o] Error 1
make[3]: Leaving directory `/root/work/hg/xen-src/xen/arch/x86'
make[2]: *** [/root/work/hg/xen-src/xen/xen] Error 2
make[2]: Leaving directory `/root/work/hg/xen-src/xen'
make[1]: *** [xen] Error 2
make[1]: Leaving directory `/root/work/hg/xen-src'
make: *** [world] Error 2
-Lifeng
[-- Attachment #1.2: Type: text/html, Size: 5517 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: how to be a kernel developer ?
From: Jesper Juhl @ 2005-07-19 1:11 UTC (permalink / raw)
To: regatta; +Cc: linux-kernel
In-Reply-To: <5a3ed56505071807357fc419e7@mail.gmail.com>
On 7/18/05, regatta <regatta@gmail.com> wrote:
> Hi
>
> I want to join the Kernel community and help in developing Linux
> kernel, I'm good in C,Perl and not that good in C++
>
The kernel is written in (mainly) C and (a little bit of) asm, no C++ in there.
> is there any How-To page in how to help or how to join ? since I want
> to start in basic things
>
A few things you should do :
- Take a look in the Documentation/ directory in the kernel source,
you'll find lots of valuable information there.
- Go check out http://kernelnewbies.org/
- You may also find this online source browser useful (I know I do)
http://lxr.linux.no/
- Keep a link to a LKML archive in your bookmarks and search the
archives for answers whenever you have a question - chances are good
that whatever you want to ask has been asked before and answered in
depth on the list, so it'll be in the archives. Here's one LKML
archive you can use, it goes back a few years :
http://www.ussg.iu.edu/hypermail/linux/kernel/
- Subscribe to LKML and start reading the some of the threads. A lot
can be learned by reading the bugreports and solutions that pop up on
the list, there are also often discussions on ideas, implementation
details, debugging etc etc that can be valuable. So join the list and
start listening :) ohh, and do read the lists FAQ at
http://www.tux.org/lkml/
- You may also want to join the Linux Kernel Janitors
http://janitor.kernelnewbies.org/ - they have a mailing list and a
nice TODO list of things that need doing - good place to pick a small
starting project from.
- You should also, most likely, invest in a few books on the kernel
and read them. I'd recommend these two as good ones to start with :
"Linux Kernel Development (2nd Edition), by Robert Love" and "Linux
Device Drivers (Third Edition), by Jonathan Corbet, Alessandro Rubini,
and Greg Kroah-Hartman".
- And most important of all, start reading the kernel source, and play
with the kernel source. Reading the source, making some changes and
then testing them and learning from the mistakes you make is a great
way to learn.
--
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
^ permalink raw reply
* RE: Failed to pass make on ia32
From: Li, Xin B @ 2005-07-19 1:13 UTC (permalink / raw)
To: Ling, Xiaofeng, Yu, Lifeng, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1670 bytes --]
seems QA are working on the public tree, right?
-Xi
________________________________
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ling, Xiaofeng
Sent: 2005年7月19日 9:10
To: Yu, Lifeng; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Failed to pass make on ia32
I can build on my machine with 5812.
Try to use hg co -C
________________________________
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Yu, Lifeng
Sent: 2005年7月19日 08:54
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Failed to pass make on ia32
On lateset changeset 5812, We failed to pass make on ia32. Anyone met with the same problem?
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/root/work/hg/xen-src/xen/include -I/root/work/hg/xen-src/xen/include/asm-x86/mach-generic -I/root/work/hg/xen-src/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c vmx.c -o vmx.o
vmx.c: In function `vmx_vmexit_handler':
vmx.c:1667: error: syntax error before '<<' token
vmx.c:1679: error: syntax error before '==' token
vmx.c:1681:25: invalid suffix "zb2zg" on floating constant
make[3]: *** [vmx.o] Error 1
make[3]: Leaving directory `/root/work/hg/xen-src/xen/arch/x86'
make[2]: *** [/root/work/hg/xen-src/xen/xen] Error 2
make[2]: Leaving directory `/root/work/hg/xen-src/xen'
make[1]: *** [xen] Error 2
make[1]: Leaving directory `/root/work/hg/xen-src'
make: *** [world] Error 2
-Lifeng
[-- Attachment #1.2: Type: text/html, Size: 6116 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Fix some warnings when building with gcc 4
From: Ian Wienand @ 2005-07-19 1:15 UTC (permalink / raw)
To: linux-ia64
Hi,
Following are some patches to fix some IA64 specific warnings I am
seeing when building with gcc 4. I'm pretty sure they can't hurt
people not using gcc 4.
The only IA64 specific one that I still see is
include/asm/mmu_context.h:67: warning: type qualifiers ignored on
function return type
This is because mmu_context_t is defined as volatile for a good reason
/*
* Type for a context number. We declare it volatile to ensure
* proper ordering when it's accessed outside of spinlock'd critical
* sections (e.g., as done in activate_mm() and init_new_context()).
*/
However, when a function returns a mmu_context_t it ends up with the
qualified return type (which according to this old message
http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00814.html doesn't mean
anything, unless something has changed). So I'm not sure what the
best solution is for that one.
Thanks,
-i
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: David Gibson @ 2005-07-19 1:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc64-dev, linuxppc-dev@ozlabs.org
In-Reply-To: <1121437857.24864.12.camel@cashmere.sps.mot.com>
On Fri, Jul 15, 2005 at 09:30:58AM -0500, Jon Loeliger wrote:
> On Fri, 2005-07-15 at 02:19, David Gibson wrote:
>
> >
> > Ok, I've merged this,
>
> Excellent, thanks!
>
> > although I've tweaked things substantially in the process.
>
> No problem.
>
> > I did rename "header_tree" to "boot_info", moved some
>
> Oh, good!
>
> > things around, and changed the syntax. Reserve ranges can now be
> > specified either as an address and length:
> >
> > /memreserve/ 10000000 00002000;
> >
> > or as an (inclusive) address range:
> >
> > /memreserve/ 10000000-10001fff;
> >
> > I am a bit worried that those two forms may be hard to distinguish at
> > a glance. Any sugggestions for changes to the syntax soon please, I'd
> > really like to keep the source syntax as stable as possible.
>
> Oh man. With syntax you can demystify those in any number
> of ways. Just a matter of what you are wanting. You can
> always add sugar:
>
> /memreserve_block/ 10000000 00002000;
> /memreserve_range/ 10000000 10001fff;
>
> /memreserve/ 10000000 /for/ 2000; // or /size/ ?
> /memreserve/ 10000000 /through/ 10001fff;
>
> /memreserve/ 10000000 00002000;
> /memreserve/ [10000000, 10001fff]; // or [10000000, 10002000)?
>
> Stuff like that maybe?
Hrm.. don't really like any of those better than what I have already,
I'm afraid. It does occur to me that size > base is going to be a
very rare situation, so the value of the numbers themselves will act
as a reasonable hint as to which form is in use.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* [PATCH] Type qualifiers in __ia64_get_io_port_base
From: Ian Wienand @ 2005-07-19 1:20 UTC (permalink / raw)
To: linux-ia64
Fix
include/asm/io.h:125: warning: type qualifiers ignored on function return type
produced by gcc 4
According to http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00814.html
the type qualifier is superfluous.
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/include/asm-ia64/io.h b/include/asm-ia64/io.h
--- a/include/asm-ia64/io.h
+++ b/include/asm-ia64/io.h
@@ -120,7 +120,7 @@ static inline void ___ia64_mmiowb(void)
ia64_mfa();
}
-static inline const unsigned long
+static inline unsigned long
__ia64_get_io_port_base (void)
{
extern unsigned long ia64_iobase;
^ permalink raw reply
* [PATCH] Fix uninitalised value in do_copy_task_regs
From: Ian Wienand @ 2005-07-19 1:22 UTC (permalink / raw)
To: linux-ia64
Fix
arch/ia64/kernel/process.c:503: warning: 'ip' may be used uninitialized in this function
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -500,7 +500,7 @@ copy_thread (int nr, unsigned long clone
static void
do_copy_task_regs (struct task_struct *task, struct unw_frame_info *info, void *arg)
{
- unsigned long mask, sp, nat_bits = 0, ip, ar_rnat, urbs_end, cfm;
+ unsigned long mask, sp, nat_bits = 0, ip = 0, ar_rnat, urbs_end, cfm;
elf_greg_t *dst = arg;
struct pt_regs *pt;
char nat;
^ permalink raw reply
* [PATCH] Fix uninitialised values in ia64_illegal_op_fault
From: Ian Wienand @ 2005-07-19 1:24 UTC (permalink / raw)
To: linux-ia64
Fix
arch/ia64/kernel/traps.c: In function 'ia64_illegal_op_fault':
arch/ia64/kernel/traps.c:444: warning: 'rv.arg3' is used uninitialized in this function
arch/ia64/kernel/traps.c:444: warning: 'rv.arg2' is used uninitialized in this function
arch/ia64/kernel/traps.c:444: warning: 'rv.arg1' is used uninitialized in this function
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/arch/ia64/kernel/traps.c b/arch/ia64/kernel/traps.c
--- a/arch/ia64/kernel/traps.c
+++ b/arch/ia64/kernel/traps.c
@@ -435,6 +435,7 @@ ia64_illegal_op_fault (unsigned long ec,
sprintf(buf, "IA-64 Illegal operation fault");
die_if_kernel(buf, ®s, 0);
+ memset(&rv, 0, sizeof(rv));
memset(&si, 0, sizeof(si));
si.si_signo = SIGILL;
si.si_code = ILL_ILLOPC;
^ permalink raw reply
* Re: how to be a kernel developer ?
From: Jesper Juhl @ 2005-07-19 1:24 UTC (permalink / raw)
To: regatta; +Cc: linux-kernel
In-Reply-To: <9a87484905071818116f7cb0de@mail.gmail.com>
On 7/19/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 7/18/05, regatta <regatta@gmail.com> wrote:
> > Hi
> >
> > I want to join the Kernel community and help in developing Linux
> > kernel, I'm good in C,Perl and not that good in C++
> >
> The kernel is written in (mainly) C and (a little bit of) asm, no C++ in there.
>
> > is there any How-To page in how to help or how to join ? since I want
> > to start in basic things
> >
> A few things you should do :
>
[snip]
A few things I forgot to mention in the first mail.
You can also help out by testing the development kernels - they need
testing by as many people as possible, so start testing the -rc
kernels and the daily git snapshots as well as the -mm kernels. Test
if they build with your usual configuration, test if they build with
"allnoconfig", "allyesconfig", "allmodconfig" and perhaps a random
config or two. Test if they boot OK, if they run OK for a longer time,
etc.
When you find a problem you can try to fix the issue yourself and send
a patch to both the mailinglist and the person responsible for the
code in question. If you are unable to fix the problem yourself, then
send a detailed bugreport to the list and the person responsible for
the code. Take a look at the REPORTING-BUGS file in the kernel source
dir and the Documentation/BUG-HUNTING file.
Helping to test pre-release kernels is a valuable effort. Run a new
kernel daily :-)
--
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
^ permalink raw reply
* [PATCH] Fix uninitalised values in efi_memmap_walk
From: Ian Wienand @ 2005-07-19 1:26 UTC (permalink / raw)
To: linux-ia64
Fix
arch/ia64/kernel/efi.c: In function 'efi_memmap_walk':
arch/ia64/kernel/efi.c:306: warning: 'prev.start' may be used uninitialized in this function
arch/ia64/kernel/efi.c:306: warning: 'prev.end' may be used uninitialized in this function
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -303,7 +303,7 @@ efi_memmap_walk (efi_freemem_callback_t
struct range {
u64 start;
u64 end;
- } prev, curr;
+ } prev = {0}, curr = {0};
void *efi_map_start, *efi_map_end, *p, *q;
efi_memory_desc_t *md, *check_md;
u64 efi_desc_size, start, end, granule_addr, last_granule_addr, first_non_wb_addr = 0;
^ permalink raw reply
* [PATCH] Fix uninitalised values in ia64_tlb_init
From: Ian Wienand @ 2005-07-19 1:28 UTC (permalink / raw)
To: linux-ia64
Fix
arch/ia64/mm/tlb.c: In function 'ia64_tlb_init':
arch/ia64/mm/tlb.c:171: warning: 'ptce_info.base' may be used uninitialized in this function
arch/ia64/mm/tlb.c:171: warning: 'ptce_info.count[0]' may be used uninitialized in this function
arch/ia64/mm/tlb.c:171: warning: 'ptce_info.count[1]' may be used uninitialized in this function
arch/ia64/mm/tlb.c:171: warning: 'ptce_info.stride[0]' may be used uninitialized in this function
arch/ia64/mm/tlb.c:171: warning: 'ptce_info.stride[1]' may be used uninitialized in this function
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/arch/ia64/mm/tlb.c b/arch/ia64/mm/tlb.c
--- a/arch/ia64/mm/tlb.c
+++ b/arch/ia64/mm/tlb.c
@@ -172,6 +172,8 @@ ia64_tlb_init (void)
unsigned long tr_pgbits;
long status;
+ memset(&ptce_info, 0, sizeof(ptce_info));
+
if ((status = ia64_pal_vm_page_size(&tr_pgbits, &purge.mask)) != 0) {
printk(KERN_ERR "PAL_VM_PAGE_SIZE failed with status=%ld;"
"defaulting to architected purge page-sizes.\n", status);
^ permalink raw reply
* [PATCH] Fix unused variable acpi_madt_rev
From: Ian Wienand @ 2005-07-19 1:31 UTC (permalink / raw)
To: linux-ia64
Fix
arch/ia64/kernel/acpi.c:71: warning: 'acpi_madt_rev' defined but not used
when building for the simulator (which has no ACPI) by moving inside
an ACPI ifdef'd area.
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -68,8 +68,6 @@ EXPORT_SYMBOL(pm_power_off);
unsigned char acpi_kbd_controller_present = 1;
unsigned char acpi_legacy_devices;
-static unsigned int __initdata acpi_madt_rev;
-
unsigned int acpi_cpei_override;
unsigned int acpi_cpei_phys_cpuid;
@@ -135,6 +133,8 @@ acpi_get_sysname (void)
#define ACPI_MAX_PLATFORM_INTERRUPTS 256
+static unsigned int __initdata acpi_madt_rev;
+
/* Array to record platform interrupt vectors for generic interrupt routing. */
int platform_intr_list[ACPI_MAX_PLATFORM_INTERRUPTS] = {
[0 ... ACPI_MAX_PLATFORM_INTERRUPTS - 1] = -1
^ permalink raw reply
* Re: Fw: Oops in hidinput_hid_event
From: Jesper Juhl @ 2005-07-19 1:31 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: vojtech, linux-kernel
In-Reply-To: <20050718141637.074c6f70.zaitcev@redhat.com>
On 7/18/05, Pete Zaitcev <zaitcev@redhat.com> wrote:
> I think this patch is rather obvious, so maybe I should ask Andrew to
> apply it to -mm for now, to get some testing. Would that help to verify
> it for acceptance?
>
> -- Pete
>
> Begin forwarded message:
>
> Date: Tue, 28 Jun 2005 15:00:23 -0700
> From: Pete Zaitcev <zaitcev@redhat.com>
> To: vojtech@suse.cz
> Cc: zaitcev@redhat.com, linux-usb-devel@lists.sourceforge.net
> Subject: Oops in hidinput_hid_event
>
> Hi, Vojtech:
>
> Someone reported a bug in Fedora, which runs a largely unmodified upstream
> kernel in this area. Whenever the user hits a key which switches LED,
> the system oopses. Here's a trace:
>
> Unable to handle kernel NULL pointer dereference at virtual address 000000c8
> EFLAGS: 00010006 (2.6.11-1.1369_FC4smp)
> EIP is at hidinput_hid_event+0x2d/0x292
> Call Trace:
> [<c02872e0>] hid_process_event+0x57/0x5f
> [<c028758a>] hid_input_field+0x2a2/0x2ac
> [<c0287632>] hid_input_report+0x9e/0xb8
> [<c0287f62>] hid_ctrl+0x14c/0x151
> [<e0a21060>] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
> [<c027dab5>] usb_hcd_giveback_urb+0x24/0x67
> [<e0a22360>] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
> [<e0a223af>] uhci_finish_completion+0x44/0x56 [uhci_hcd]
> [<e0a224a2>] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
> [<c023413d>] i8042_interrupt+0x121/0x234
> [<e0a226d0>] uhci_irq+0x47/0x10d [uhci_hcd]
>
> Full trace at
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
>
> Any ideas?
>
> By the way, it seems that I see a bug in hidinput_hid_event.
> The check for NULL can never work, becaue &hidinput->input
> is nonzero at all times. How about this?
>
> --- linux-2.6.12/drivers/usb/input/hid-input.c 2005-06-21 12:58:47.000000000 -0700
> +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c 2005-06-28 14:57:22.000000000 -0700
> @@ -397,11 +397,12 @@
>
> void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> {
> - struct input_dev *input = &field->hidinput->input;
> + struct input_dev *input;
> int *quirks = &hid->quirks;
>
> - if (!input)
> + if (!field->hidinput)
How about
if (!field || !field->hdinput)
instead?
> return;
> + input = &field->hidinput->input;
Add a
if (!input)
return;
check here?
>
> input_regs(input, regs);
>
>
> -- Pete
--
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
^ permalink raw reply
* Re: Fw: Oops in hidinput_hid_event
From: Jesper Juhl @ 2005-07-19 1:34 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: vojtech, linux-kernel
In-Reply-To: <9a874849050718183175bc08d4@mail.gmail.com>
On 7/19/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 7/18/05, Pete Zaitcev <zaitcev@redhat.com> wrote:
> > I think this patch is rather obvious, so maybe I should ask Andrew to
> > apply it to -mm for now, to get some testing. Would that help to verify
> > it for acceptance?
> >
> > -- Pete
> >
> > Begin forwarded message:
> >
> > Date: Tue, 28 Jun 2005 15:00:23 -0700
> > From: Pete Zaitcev <zaitcev@redhat.com>
> > To: vojtech@suse.cz
> > Cc: zaitcev@redhat.com, linux-usb-devel@lists.sourceforge.net
> > Subject: Oops in hidinput_hid_event
> >
> > Hi, Vojtech:
> >
> > Someone reported a bug in Fedora, which runs a largely unmodified upstream
> > kernel in this area. Whenever the user hits a key which switches LED,
> > the system oopses. Here's a trace:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 000000c8
> > EFLAGS: 00010006 (2.6.11-1.1369_FC4smp)
> > EIP is at hidinput_hid_event+0x2d/0x292
> > Call Trace:
> > [<c02872e0>] hid_process_event+0x57/0x5f
> > [<c028758a>] hid_input_field+0x2a2/0x2ac
> > [<c0287632>] hid_input_report+0x9e/0xb8
> > [<c0287f62>] hid_ctrl+0x14c/0x151
> > [<e0a21060>] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
> > [<c027dab5>] usb_hcd_giveback_urb+0x24/0x67
> > [<e0a22360>] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
> > [<e0a223af>] uhci_finish_completion+0x44/0x56 [uhci_hcd]
> > [<e0a224a2>] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
> > [<c023413d>] i8042_interrupt+0x121/0x234
> > [<e0a226d0>] uhci_irq+0x47/0x10d [uhci_hcd]
> >
> > Full trace at
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
> >
> > Any ideas?
> >
> > By the way, it seems that I see a bug in hidinput_hid_event.
> > The check for NULL can never work, becaue &hidinput->input
> > is nonzero at all times. How about this?
> >
> > --- linux-2.6.12/drivers/usb/input/hid-input.c 2005-06-21 12:58:47.000000000 -0700
> > +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c 2005-06-28 14:57:22.000000000 -0700
> > @@ -397,11 +397,12 @@
> >
> > void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> > {
> > - struct input_dev *input = &field->hidinput->input;
> > + struct input_dev *input;
> > int *quirks = &hid->quirks;
> >
> > - if (!input)
> > + if (!field->hidinput)
>
> How about
> if (!field || !field->hdinput)
> instead?
>
> > return;
> > + input = &field->hidinput->input;
>
> Add a
> if (!input)
> return;
> check here?
>
Ehh, I must have been sleeping, disregard this last bit...
--
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
^ permalink raw reply
* [PATCH] Fix unused variable cpe_poll_timer
From: Ian Wienand @ 2005-07-19 1:35 UTC (permalink / raw)
To: linux-ia64
Fix
arch/ia64/kernel/mca.c:109: warning: 'cpe_poll_timer' defined but not used
when building for the simulator, which has no ACPI
--
Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -106,7 +106,9 @@ static ia64_mc_info_t ia64_mc_info;
#define CPE_HISTORY_LENGTH 5
#define CMC_HISTORY_LENGTH 5
+#ifdef CONFIG_ACPI
static struct timer_list cpe_poll_timer;
+#endif
static struct timer_list cmc_poll_timer;
/*
* This variable tells whether we are currently in polling mode.
^ permalink raw reply
* Re: Regarding KDB for REDHAT9.0
From: Keith Owens @ 2005-07-19 1:41 UTC (permalink / raw)
To: Subbu; +Cc: linux-kernel, linux-net, subbu2k_av
In-Reply-To: <Pine.GSO.4.30.0507181124560.28721-100000@sunrnd2.sasken.com>
On Mon, 18 Jul 2005 11:29:39 +0530 (IST),
Subbu <subbu@sasken.com> wrote:
> I have REDHAT 9.0 (kernel version 2.4.20-8) and i want to have KDB.
>please tell me which version of KDB i can use with redhat 9.0 and above
>mentioned kernel version.
Sorry, not available. RedHat do not want kdb so SGI do not do KDB
patches against RedHat distributions. Use SuSE instead, that has KDB
built in.
^ permalink raw reply
* RE: Failed to pass make on ia32
From: Yu, Lifeng @ 2005-07-19 1:42 UTC (permalink / raw)
To: Ling, Xiaofeng, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1566 bytes --]
Thanks! It can pass now.
-Lifeng
________________________________
From: Ling, Xiaofeng
Sent: 2005年7月19日 9:10
To: Yu, Lifeng; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] Failed to pass make on ia32
I can build on my machine with 5812.
Try to use hg co -C
________________________________
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Yu, Lifeng
Sent: 2005年7月19日 08:54
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Failed to pass make on ia32
On lateset changeset 5812, We failed to pass make on ia32. Anyone met with the same problem?
gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe -I/root/work/hg/xen-src/xen/include -I/root/work/hg/xen-src/xen/include/asm-x86/mach-generic -I/root/work/hg/xen-src/xen/include/asm-x86/mach-default -O3 -fomit-frame-pointer -msoft-float -m32 -march=i686 -DNDEBUG -c vmx.c -o vmx.o
vmx.c: In function `vmx_vmexit_handler':
vmx.c:1667: error: syntax error before '<<' token
vmx.c:1679: error: syntax error before '==' token
vmx.c:1681:25: invalid suffix "zb2zg" on floating constant
make[3]: *** [vmx.o] Error 1
make[3]: Leaving directory `/root/work/hg/xen-src/xen/arch/x86'
make[2]: *** [/root/work/hg/xen-src/xen/xen] Error 2
make[2]: Leaving directory `/root/work/hg/xen-src/xen'
make[1]: *** [xen] Error 2
make[1]: Leaving directory `/root/work/hg/xen-src'
make: *** [world] Error 2
-Lifeng
[-- Attachment #1.2: Type: text/html, Size: 9343 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Problems with Routing (was RE: [LARTC] Losing Packets after a DNAT in
From: Jefferson Cowart @ 2005-07-19 1:45 UTC (permalink / raw)
To: lartc
Wel that helped, but I'm still having problems.
Here is what is happening now:
I send a packet from 134.173.94.7 to 134.173.95.146 (those devices are on
the same network).
It goes into my router on eth2 and gets DNATed to 192.168.5.9 which is on
eth3.
It gets routed properly and gets to my machine at 192.168.5.9.
My machine at 192.168.5.9 responds.
It goes back into my router on eth3.
My router routes the packet out eth0 and the automatic rule sets to source
address back to 134.173.95.146.
Since the packet has a source address that is on the wrong interface the
packet is dropped. It appears that my problem is that I need it to route the
connection back out the same interface that it came in on. However for new
connections I need it to use eth0 as the default route.
----------------
Thanks
Jefferson Cowart
Jeff@cowart.net
> -----Original Message-----
> From: pramod [mailto:pramod@atheros.com]
> Sent: Sunday, July 17, 2005 22:08
> To: Jefferson Cowart
> Cc: lartc@mailman.ds9a.nl
> Subject: Re: [LARTC] Losing Packets after a DNAT in prerouting
>
> I am sorry
> In the second option i did a mistake
> Do the following things...
> 1) Restore the arp_filter to default..
> 2) Set rp_filter to 0 (zero)
>
> thanks
> pramod
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: repeated Oops on Kernel 2.6.12.2
From: Jesper Juhl @ 2005-07-19 1:54 UTC (permalink / raw)
To: Parminder Chhabra; +Cc: linux-kernel
In-Reply-To: <20050718042523.275E41CE304@ws1-6.us4.outblaze.com>
On 7/18/05, Parminder Chhabra <parminderchhabra@email.com> wrote:
> Hi,
>
> I get repeated Oops messages on 2.6.12.2. I get the message on inserting a
Have you tested a more recent kernel like 2.6.13-rc3 or
2.6.13-rc3-git4 or 2.6.13-rc3-mm1 to see if the problem is already
solved?
> module that spawns a kernel thread to perform a task on a group of packets.
Perhaps you could provide the code for that module somewhere?
Sorry I can't be of more help.
--
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
^ permalink raw reply
* Re: 2.6.12-rc2 and as-iosched
From: Kenneth Parrish @ 2005-07-19 1:58 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20050718134933.GA1890@suse.de>
-=> axboe@suse.de wrote to Kenneth Parrish <=-
ax> ok, AS is definitely broken, it does an internal HZ <-> msec
ax> conversion in the store/show functions as well. This should fix
ax> it.
thank ya :-)
^ permalink raw reply
* DNAT
From: Kai Hendry @ 2005-07-19 2:01 UTC (permalink / raw)
To: netfilter
I have three machines:
192.168.0.1
192.168.0.3
192.168.0.9
On 9 there is service running on port 1199 that I want clients (at 3) to
use from 1.
With SSH I can get this working from 1 with clients at 1 with:
ssh -L 1199:localhost:1199 192.168.0.9
Thought telnet localhost 1199 only works, not telnet 192.168.0.1 1199
Anyway, I don't need encryption.
DNAT is what I've been told I need so:
http://netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html
$ cat i.sh
sudo /sbin/iptables -t nat -F
# This alone doesn't work
sudo /sbin/iptables -t nat -A PREROUTING -p tcp --dport 1199 -i eth0 -j
DNAT --to 192.168.0.9:1199
# I suspect something is wrong here:
sudo /sbin/iptables -t nat -A POSTROUTING -p tcp --dport 1199 -j SNAT
--to 192.168.0.1:1199
sudo /sbin/iptables -t nat -vnxL --line-numbers
It just does not work when from 3:
$ telnet 192.168.0.1 1199
Trying 192.168.0.1...
Packets do show up:
SOLTEC-HDSVR$ sudo /sbin/iptables -t nat -vnxL --line-numbers
Chain PREROUTING (policy ACCEPT 6494 packets, 466878 bytes)
num pkts bytes target prot opt in out
source destination
1 4 240 DNAT tcp -- eth0 *
0.0.0.0/0 0.0.0.0/0 tcp dpt:1199 to:192.168.0.9:1199
Chain POSTROUTING (policy ACCEPT 2102 packets, 388967 bytes)
num pkts bytes target prot opt in out
source destination
Chain OUTPUT (policy ACCEPT 2102 packets, 388967 bytes)
num pkts bytes target prot opt in out
source destination
Though from 1 not at all:
$ telnet 192.168.0.1 1199
Trying 192.168.0.1...
telnet: Unable to connect to remote host: Connection refused
What am I doing wrong?
^ permalink raw reply
* Re: [PATCH] Type qualifiers in __ia64_get_io_port_base
From: david mosberger @ 2005-07-19 2:06 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20050719012027.GA10518@cse.unsw.EDU.AU>
This one is wrong. It should use __attribute_const__ instead. If you
just drop the "const", it will result in worse code.
--david
On 7/18/05, Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
> Fix
>
> include/asm/io.h:125: warning: type qualifiers ignored on function return type
>
> produced by gcc 4
>
> According to http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00814.html
> the type qualifier is superfluous.
>
> --
>
> Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>
>
> diff --git a/include/asm-ia64/io.h b/include/asm-ia64/io.h
> --- a/include/asm-ia64/io.h
> +++ b/include/asm-ia64/io.h
> @@ -120,7 +120,7 @@ static inline void ___ia64_mmiowb(void)
> ia64_mfa();
> }
>
> -static inline const unsigned long
> +static inline unsigned long
> __ia64_get_io_port_base (void)
> {
> extern unsigned long ia64_iobase;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [lm-sensors] drivers/w1/w1_int.c compile error with NET=n
From: Adrian Bunk @ 2005-07-19 2:06 UTC (permalink / raw)
To: johnpol; +Cc: lm-sensors, linux-kernel
I'm seeing the following compile error in 2.6.13-rc3-mm1 (but it doesn't
seem to be specific to -mm) with CONFIG_NET=n:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o: In function `w1_alloc_dev':
w1_int.c:(.text+0x65d81f): undefined reference to `netlink_kernel_create'
w1_int.c:(.text+0x65d881): undefined reference to `sock_release'
drivers/built-in.o: In function `w1_free_dev':
w1_int.c:(.text+0x65d8e9): undefined reference to `sock_release'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: DTC memory reserve question
From: Benjamin Herrenschmidt @ 2005-07-19 2:08 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1121718331.2400.24.camel@cashmere.sps.mot.com>
On Mon, 2005-07-18 at 15:25 -0500, Jon Loeliger wrote:
> So, when the Device Tree Compiler lays down a memory
> reserve table into an assembly file, it always adds
> a reserved region covering the whole DT blob itself.
> That is, it does this:
>
> .balign 8
> .globl dt_reserve_map
> dt_reserve_map:
> _dt_reserve_map:
> .long 0, _dt_blob_start
> .long 0, _dt_blob_end - _dt_blob_start
> .llong 0
> .llong 0
>
> Naturally, that yields System.map entries like this:
>
> c0013988 t _dt_blob_start
> c0013988 T dt_blob_start
> c0013988 t _dt_header
> c0013988 T dt_header
> c00139b0 t _dt_reserve_map
> c00139b0 T dt_reserve_map
> c00139d0 t _dt_struct_start
> c00139d0 T dt_struct_start
> c0013df0 t _dt_strings_start
> c0013df0 T dt_strings_start
> c0013df0 t _dt_struct_end
> c0013df0 T dt_struct_end
> c0013f05 t _dt_blob_end
> c0013f05 T dt_blob_end
>
> Notice that these are 0xC-gazillion addresses.
How are you getting these addresses ? You are trying to link the output
of dtc with the kernel directly ? Hrm... That will not work for that
(and maybe a couple of other things). Might be better to link it with
the zImage wrapper...
Ben.
^ permalink raw reply
* PATCH: Re: [U-Boot-Users] malloc with no return check?
From: Travis B. Sawyer @ 2005-07-19 2:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <c166aa9f050718140870446f97@mail.gmail.com>
Andrew Dyer wrote:
> I noticed the au1xxx ethernet driver has a malloc where the return
> value isn't checked.
> I did some more looking while waiting for a slow flash programmer and at least
> these files seem to do the same thing:
>
> ./cpu/ppc4xx/440gx_enet.c
>
Here's a patch to fix 440gx_enet.c
CHANGELOG
Patch by Travis B. Sawyer, 18 July 2005
Check return value of malloc in 440gx_enet.c
Best regards,
Travis
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 440gx_malloc_fix.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050718/e960ba8a/attachment.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.