Hi Castor, Can you re-create your latest patch so that it applies like the one it's replacing?
Here's the patch you're replacing: $ lsdiff crash-4.0-3.14-sym.patch crash-4.0-3.14/defs.h crash-4.0-3.14/gdb-6.1/gdb/symtab.c crash-4.0-3.14/kernel.c crash-4.0-3.14/symbols.c $ $ patch -p1 --dry-run < crash-4.0-3.14-sym.patch patching file defs.h patching file gdb-6.1/gdb/symtab.c patching file kernel.c patching file symbols.c $ Here's your latest: $ lsdiff crash-4.0-3.14-sym.1.patch $ $ patch -p1 --dry-run < crash-4.0-3.14-sym.1.patch can't find file to patch at input line 2 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -x Makefile crash-4.0-3.14/defs.h crash-4.0-3.14-sym/defs.h -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 6 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -x Makefile crash-4.0-3.14/gdb-6.1/gdb/symtab.c crash-4.0-3.14-sym/gdb-6.1/gdb/symtab.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 17 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -x Makefile crash-4.0-3.14/kernel.c crash-4.0-3.14-sym/kernel.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 44 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r -x Makefile crash-4.0-3.14/symbols.c crash-4.0-3.14-sym/symbols.c -------------------------- File to patch: Skip this patch? [y] Skipping patch. 11 out of 11 hunks ignored $ Castor Fu wrote: > Oops, I found some problems with that version... Some data was not > alwaysinitialized and there were some things which > were just lucky to work.I've attached a new patch.Sorry about that folks, > castor > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Castor Fu > Sent: Monday, December 04, 2006 11:16 AM > To: Discussion list for crash utility usage, maintenance and development > Subject: RE: [Crash-utility] modules and data / bss initialization > > I'm attaching a revised patch against 4.0-3.14... This shouldwork a bit > better as I no longer make > assumptions about the orderingof symbols, it's less whiny, and I even > compiled with with -Werror sothose > sign-extension problems should be gone.Thanks for the feedback! > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave > Anderson > Sent: Friday, December 01, 2006 11:46 AM > To: Discussion list for crash utility usage, maintenance and > development > Subject: Re: [Crash-utility] modules and data / bss initialization > > Castor Fu wrote: > > > I don't think this made it out earlier...Here's a fix. I've also > added something so > > 'MODULES_IN_CWD' will work on 2.6since modules will end with .koI > hope this looks good to > > others.... > > > Hi Castor, > > Upon quick testing with RHEL4 and RHEL5 x86_64 kernels, > this patch certainly looks promising... > > Although I don't particularly care to see these messages: > > ffffffff8810ae80 serio_raw 41157 > > /lib/modules/2.6.18-1.2747.el5/kernel/drivers/input/serio/serio_raw.ko > ffffffff8811b580 uhci_hcd 59353 > /lib/modules/2.6.18-1.2747.el5/kernel/drivers/usb/host/uhci-hcd.ko > ffffffff88130b00 shpchp 73069 > /lib/modules/2.6.18-1.2747.el5/kernel/drivers/pci/hotplug/shpchp.ko > unexpected sym __key.10825 8814a180 sec .bss offset e180 mod_base > 8813c000 > XXX sym __key.10825 @ 8814a180 bfd val 0 section .bss > unexpected sym __key.10826 8814a180 sec .bss offset e180 mod_base > 8813c000 > XXX sym __key.10826 @ 8814a180 bfd val 0 section .bss > ffffffff88141f80 i2c_core 57793 > /lib/modules/2.6.18-1.2747.el5/kernel/drivers/i2c/i2c-core.ko > > I would think they could be CRASHDEBUG(1)'d, couldn't they? > Plus, those error messages will clip 64-bit values as shown > above. > > I'm also presuming that the new add-symbol-file operation will > harmlessly take a "0" mod_data_start, mod_rodata_start or > mod_bss_start address argument; seemingly it does, since several > of my test modules have 0 as one or more of those start addresses. > > Anyway, I also would be interested in the experiences of others > on the list who are using different architectures and kernel > versions. > > Thanks, > Dave > > > > > > > > > ----------------------------------------------------------------------------------------------------------- > -- > Crash-utility mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/crash-utility >
-- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
