[ bseseuum9jzw9ujl] : marketing list for businesses in the UK

Healthcare List Package: $295 for all 21 complete lists below
 - Also available, Business Lists, Foregin Business Lists and Consumer data

Physicians (34 specialties)
Database	:	 788k records, 17k emails, 200k fax numbers

Chiropractors
Database	:	 108,421 total records * 3,414 emails * 6,553 fax numbers

Alternative Medicine
Database	:	 1,141,602 total records with 36,320 emails and 38.935 fax numbers

Dentists
Database	:	 164k records, 45k emails, 77k fax numbers

Dentists with Specialties
Database	:	 30k records all with emails

	
Veterinarians
Database	:	 78,986 total records with 1,438  emails and 1,050  fax numbers

Hospitals
Database	:	 10,661 Emails for hospitals in the USA

Nursing Homes
Database	:	 31,589 Senior Administrators, 11,288 Nursing Directors in over 14,706 Nursing Homes (full
contact info no emails)

Pharmaceutical Companies

Re: [RFC Patch 4/6] PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information

----- Original Message -----
> On Wed, Jun 01, 2011 at 01:18:16PM -0400, Dave Anderson wrote:
> > FWIW, unlike mcelog, it really doesn't have to be maintained in the crash
> > utility. It's just another kernel data structure whose contents can be
> > determined dynamically during runtime:
> >
> 
> That's what I was wondering. Why can't we simple extract the contents
> of this structure from /proc/vmcore and save it, instead of trying to
> export it by appending additional elf notes to vmcore.

Actually I take that back -- Prasad's patch looks at the ELF header
contents and exits before the crash utility invokes the embedded gdb, 
so the structure contents are unavailable at that time.  It doesn't even 
use the vmlinux file.  

Dave 

> 
> Thanks
> Vivek
> 
> >   crash> struct mce
> >   struct mce {
> >       __u64 status;
> >       __u64 misc;
> >       __u64 addr;
> >       __u64 mcgstatus;
> >       __u64 ip;

copy of /proc/vmcore

Hello,

The /proc/vmcore is not present before or after the crash

I load the kernel from grub pass parameter: crashkernel=256M mem=2048M
bootmem_debug
and then kexec -p bzImage --append="root=/dev/sda5 maxcpus=1 irqpool
reset_devices"
so i send request : echo c > /proc/sysrq-trigger

ok the kernel broken is loaded

Now i have a question:
The system is stopped and i receive the message:
Switching back to console

I assume that i need force reboot in this point, because system is freezed.

i dont see the /proc/vmcore , /dev/oldmem contains few datas

I miss some step?

--

-- 
yermandu

_______________________________________________
kexec mailing list
kexec@...

Re: [RFC][PATCH] Kexec support for PPC440x

Suzuki Poulose wrote:
>>> The way you setup the 1:1 mapping should be close to what you are 
>>> doing on
>>> kernel entry.Isn't it possible to include the file here and in the entry
>>> code?
> 
>> I will make this change and resend the patch.
> 
> I took a look at the way we do it at kernel entry. It looks more cleaner 
> to leave
> it untouched. Especially, when we add the support for 47x in the future, 
> the code
>  will become more unreadable.
> 
> What do you think ?

So the entry code has one 256MiB mapping, you need 8 of those. Entry goes 
for TLB 63 and you need to be flexible and avoid TLB 63 :).
So after all you don't have that much in common with the entry code. If
you look at the FSL-book code then you will notice that I tried to share
some code.

I don't understand why you don't flip the address space bit. On fsl we
setup the tmp mapping in the "other address" space so we don't have two
mappings for the same address. The entry code could be doing this with STS
bit, I'm not sure.

If you want to keep your tiny mmu flip code instead of merging with the
entry code then please don't put it into a separate file. The only reason
why I did it, is to have the code once since I can't branch to it and I

makedumpfile-1.3.8: Fix dump refiltering for s390x.

Hi,

makedumpfile version 1.3.8 is released.
Your comments/patches are welcome.

Changelog:
o Bugfix
 - [PATCH] makedumpfile: s390x: Fix dump refiltering for s390x. (by Mahesh Salgaonkar) Commit ID=f30ba66
 - [PATCH] s390x: Fix KVBASE to correct value for s390x architecture (by Mahesh Salgaonkar) Commit ID=c69f915
 - [PATCH] Copy correct nr_cpus info to dumpfile during re-filtering. (by Mahesh Salgaonkar) Commit ID=c4f1c98
 - [PATCH] BUGFIX: Avoid SIGSEGV when specifying -V option. (by Ken'ichi Ohmichi) Commit ID=5b8c2da

Explanation of makedumpfile:
  To shorten the size of the dumpfile and the time of creating the
  dumpfile, makedumpfile copies only the necessary pages for analysis
  to the dumpfile from /proc/vmcore. You can specify the kind of
  unnecessary pages with dump_level. If you want to shorten the size
  further, enable the compression of the page data.

Download:
  You can download the latest makedumpfile from the following URL.
  Details of the change are written on the git page of the following site.
  https://sourceforge.net/projects/makedumpfile/

Method of installation:
  You can compile the makedumpfile command as follows;
  1. "tar -zxvf makedumpfile-x.y.z.tar.gz"
  2. "cd makedumpfile-x.y.z"
  3. "make; make install"

Re: [RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg

Suzuki Poulose wrote:
> Could you please let me know your thoughts/comments about this patch ?

I'm mostly fine with it.

Maaxim copied fs2dt.c from ppc64 to ppc. So I guess ppc64 has the same
problem. ARM and MIPS is soon having DT support and kexec is probably also
on their list so I would hate to see them to either copy the DT parsing
file or having their own implementation.

Maybe we should try to use libfdt for dt parsing. It has /proc import
support so it should be fine for our needs. It is already in tree and used
by ppc32 if a basic dtb is specified. I'm not sure if the /proc interface
is part of dtc or libfdt.

I'm not saying this has to be done now but maybe later before ARM and/or
MIPS comes along needs something similar for their needs. If the libfdt is
too complex for sucking in the dtb from /proc then maybe something else
that generic and can be shared between booth ppc architectures and the
other ones.

> Thanks
> Suzuki
> 
>>
>> Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
>> ===================================================================
>> --- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
>> +++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
>>  <at>  <at>  -34,6 +35,92  <at>  <at>  unsigned int rtas_base, rtas_size;

RE: [RFC][PATCH] powerpc: Use the #address-cells information to parsememory/reg

> > Changed the add_usable_mem_property() to accept FILE* fp instead of
int fd,
> > as most of the other users of read_memory_region_limits() deals with
FILE*.
> >
> > Signed-off-by: Suzuki K. Poulose <suzuki@...>
> 
> Could you please let me know your thoughts/comments about this patch ?

Is the change to use 'FILE *' actually progress?
I'd have thought that the randomly aligned read/lseek system calls
that this allows to happen are not desirable for anything that
isn't a true file.

I'd also suggest that the sizeof's should be applied to the
actual type of the variable being read/written, not arbitrarily
'long' or 'int', and this probably ought to be some fixed size type.

	David

Re: [RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg

On 06/06/11 14:21, Sebastian Andrzej Siewior wrote:
> Suzuki Poulose wrote:
>> Could you please let me know your thoughts/comments about this patch ?
>
> I'm mostly fine with it.
>
> Maaxim copied fs2dt.c from ppc64 to ppc. So I guess ppc64 has the same
> problem.

Yes, you are right. Porting this patch over to ppc64 is in my TODO list.

> ARM and MIPS is soon having DT support and kexec is probably also
> on their list so I would hate to see them to either copy the DT parsing
> file or having their own implementation.
>
> Maybe we should try to use libfdt for dt parsing. It has /proc import
> support so it should be fine for our needs. It is already in tree and used
> by ppc32 if a basic dtb is specified. I'm not sure if the /proc interface
> is part of dtc or libfdt.
>
> I'm not saying this has to be done now but maybe later before ARM and/or
> MIPS comes along needs something similar for their needs. If the libfdt is
> too complex for sucking in the dtb from /proc then maybe something else
> that generic and can be shared between booth ppc architectures and the
> other ones.
OK

>>> Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
>>> ===================================================================
>>> --- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c

[RFC][PATCH] kexec-tools: powerpc: Use the #address-cells information to parsememory/reg - V2

Hi,

This is version 2 of the patch

Changes from Version 1 :
  : Changed the interface for read_memory_region_limits to use 'int fd'
	instead of FILE*.
  : Use sizeof(variable) for read(, instead of sizeof(type).

---

Fix parsing of the memory region information from the device-tree.

The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).

This patch introduces a read_memory_region_limits(), which parses the
memory/reg contents based on the values of #address-cells and #size-cells.

Signed-off-by: Suzuki K. Poulose <suzuki@...>

---
  kexec/arch/ppc/crashdump-powerpc.c |   33 +------
  kexec/arch/ppc/fs2dt.c             |   14 ---
  kexec/arch/ppc/kexec-ppc.c         |  158 ++++++++++++++++++++++++++-----------
  kexec/arch/ppc/kexec-ppc.h         |    6 +
  4 files changed, 129 insertions(+), 82 deletions(-)

Re: [RFC Patch 4/6] PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information

On Tue, May 31, 2011 at 11:10:43PM +0530, K.Prasad wrote:
> On Fri, May 27, 2011 at 11:04:06AM -0700, Eric W. Biederman wrote:
> > "K.Prasad" <prasad@...> writes:
> > 
> > > PANIC_MCE: Introduce a new panic flag for fatal MCE, capture related information
> > >
> > > Fatal machine check exceptions (caused due to hardware memory errors) will now
> > > result in a 'slim' coredump that captures vital information about the MCE. This
> > > patch introduces a new panic flag, and new parameters to *panic functions
> > > that can capture more information pertaining to the cause of crash.
> > >
> > > Enable a new elf-notes section to store additional information about the crash.
> > > For MCE, enable a new notes section that captures relevant register status
> > > (struct mce) to be later read during coredump analysis.
> > 
> > There may be a reason to pass everything struct mce through 5 layers of
> > code but right now it looks like it just makes everything uglier to no
> > real purpose.
> 
> We could have stopped with just a blank elf-note of type NT_MCE
> indicating an MCE triggered panic, but dumping 'struct mce' in it will
> help gather more useful information about the error - especially the
> memory address that experienced unrecoverable error (stored in
> mce->addr).
> 
> The patch 6/6 for the 'crash' tool enabled decoding of 'struct
> mce' to show this information (although the sample log in patch 0/6)
> didn't show these benefits because 'mce-inject' tool used to soft-inject
> these errors doesn't populate all registers with valid contents.
>