All of lore.kernel.org
 help / color / mirror / Atom feed
* romfs
From: Garst R. Reese @ 2002-12-11 23:38 UTC (permalink / raw)
  To: linux-kernel

Is there a current maintainer for romfs?
pls cc me.
Thanks, 
  Garst

^ permalink raw reply

* [PATCH] (2/2) i386 discontigmem support against 2.4.21pre1:  discontigmem
From: Patricia Gaughen @ 2002-12-11 23:35 UTC (permalink / raw)
  To: marcelo; +Cc: linux-kernel

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

This patch provides generic discontiguous memory support for the i386
numa architecture.  The patch also provides supports for the ia32 IBM
NUMA-Q hardware platform.  John Stultz also has added support for the
x440 hardware, but now it's mine.  This will be posted separately at a 
later date.  A version of this patch has been accepted into the v2.5
tree starting with 2.5.34.

This patch depends on the paddr->pfn patch that I just sent out.

Assumptions made: 

        - that the first node has at least 900Mb of memory

Testing done: 

        - single proc desktop pc (CONFIG_X86_NUMAQ is not set)
        - 4 proc SMP system (CONFIG_X86_NUMAQ is not set)
        - 4 proc SMP system (CONFIG_X86_NUMAQ is not set, CONFIG_HIGHMEM=64GB)
        - 16 proc NUMA box with 4GB memory (CONFIG_X86_NUMAQ=y, 
		CONFIG_NUMA is not set)
        - 16 proc NUMA box with 4GB memory (CONFIG_X86_NUMAQ=y, 
		CONFIG_NUMA is not set, CONFIG_HIGHMEM=64GB)
        - 16 proc NUMA box with 4GB memory (CONFIG_X86_NUMAQ=y, 
		CONFIG_NUMA=y)
        - 16 proc NUMA box with 4GB memory (CONFIG_X86_NUMAQ=y, 
		CONFIG_NUMA=y, CONFIG_HIGHMEM=64GB)
        - 8 proc NUMA box with 8GB memeory (CONFIG_X86_NUMAQ=y, 
		CONFIG_NUMA=y, CONFIG_HIGHMEM=64GB)
	- 16 proc NUMA box with 16GB memory (CONFIG_X86_NUMAQ=y, 
		CONFIG_NUMA=y, CONFIG_HIGHMEM=64GB)

Any and all feedback regarding this patch is greatly appreciated.

Thanks,
Pat

-- 
Patricia Gaughen (gone@us.ibm.com)
IBM Linux Technology Center
http://www.ibm.com/linux/ltc/

[-- Attachment #2: linux-2.4.21-pre1_discontig_A1.patch --]
[-- Type: application/x-patch , Size: 39457 bytes --]

^ permalink raw reply

* [PATCH] (1/2) i386 discontigmem support against 2.4.21pre1:  paddr_to_pfn
From: Patricia Gaughen @ 2002-12-11 23:35 UTC (permalink / raw)
  To: marcelo; +Cc: linux-kernel

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


This patch was originally written by Martin Bligh.

It changes all references of node_start_paddr and zone_start_paddr 
to node_start_pfn and zone_start_pfn.  This change is required to 
support PAE for i386 discontigmem.  It allows a starting address 
for a node or zone to be greater than 4GB. A version of this patch 
is in the 2.4 aa tree and has also been accepted into the v2.5 tree 
starting with 2.5.34.

I've tested this patch on the following configurations: UP, SMP, SMP PAE, 
multiquad, multiquad PAE, multiquad DISCONTIGMEM, multiquad DISCONTIGMEM PAE.

Any and all feedback regarding this patch is greatly appreciated.

Thanks,
Pat

-- 
Patricia Gaughen (gone@us.ibm.com)
IBM Linux Technology Center
http://www.ibm.com/linux/ltc/


[-- Attachment #2: linux-2.4.21-pre1_paddr-to-pfn_A1.patch --]
[-- Type: application/x-patch , Size: 14001 bytes --]

^ permalink raw reply

* [parisc-linux] Re: Solved: Kernel crash when loggin in via ssh
From: M. Grabert @ 2002-12-11 23:29 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: parisc-linux
In-Reply-To: <20021211063321.GB10185@systemhalted>

On Wed, 11 Dec 2002, Carlos O'Donell wrote:

> Subject: Re: [parisc-linux] Kernel crash when loggin in via ssh
>
> > Reading my previous post about the change in the Voodoo3 issue (Nov 26),
> > I realized that linux-2.4.20-rc1-pa7 obviously also worked.
> > This kernel was definitely compiled with gcc-3.0.4 (the one that
> > was in sid as of Nov 26).
> >
> > Yes, it might be a gcc issue ... haven't thought of that ...
> > I'll try to recompile the latest kernel with a gcc-3.0.4 - tomorrow!

It IS a gcc issue.

gcc-3.0_3.0.4-13 produces a working kernel, gcc-3.2-3.2.2-0pre0 produces
a miscompiled kernel (faulty networking, causes kernel crash).
I made NO updates whatsoever; same kernel configuration, just using gcc-3.0
insted of gcc-3.2. I just make a make clean; make dep; make vmlinux ...

Since now all my kernels compiled with gcc-3.0 were working, just when I
upgraded to gcc-3.2 the problems occured.

> So the urban legend goes that gcc-3.2 compiled kernels may infact
> produce mildly incorrect results in the networking code.

I think it is no urban legend anymore ... :-/
I've also see quite alot reports on p-l about miscompiled kernels with
anything other than gcc-3.0.4, actually several months ago; so I thought
these issues have been solved by now ...

> I have yet to verify this, and JDA seems to indicate that he has working
> kernels with gcc-3.2. While I've only recently tested gcc-3.0.x and
> gcc-3.1.x based compiles.
>
> I don't like urban legends >:} *Added item to Chrismas todo list*

Merry christmas then :-}

greetings max

^ permalink raw reply

* Re: module-init-tools 0.9.3 -- "missing" issue
From: Jean Tourrilhes @ 2002-12-11 23:37 UTC (permalink / raw)
  To: ALESSANDRO.SUARDI; +Cc: linux-kernel, rusty
In-Reply-To: <6561098.1039621998327.JavaMail.nobody@web55.us.oracle.com>

On Wed, Dec 11, 2002 at 07:53:18AM -0800, ALESSANDRO.SUARDI wrote:
> 
> Yep, it's smc-ircc :)
> 
> Dec 10 22:57:36 dolphin kernel: IrCOMM protocol (Dag Brattli)
> Dec 10 22:57:36 dolphin irattach: executing: '/sbin/modprobe irda0'
> Dec 10 22:57:36 dolphin kernel: found SMC SuperIO Chip (devid=0x09 rev=08 base=0x03f0): FDC37N958FR
> Dec 10 22:57:36 dolphin kernel: SMC IrDA Controller found
> Dec 10 22:57:36 dolphin kernel:  IrCC version 1.1, firport 0x290, sirport 0x3e8 dma=3, irq=4
> Dec 10 22:57:36 dolphin irattach: + FATAL: Error inserting smc_ircc
> (/lib/modules/2.5.51/kernel/smc-ircc.ko): No such device
> Dec 10 22:57:36 dolphin irattach: Trying to load module irda0 exited with status 1
> Dec 10 22:57:36 dolphin irattach: executing: 'echo 1 >
> /proc/sys/net/irda/discovery'
> Dec 10 22:57:36 dolphin irattach: Starting device irda0
> Dec 10 22:57:36 dolphin kernel: Module irda cannot be unloaded due to unsafe usage in net/irda/af_irda.c:1146
> 
> Should I give up on it and go for Daniele's smsc-ircc2 ? I confess I hadn't
>  used 2.5.xx for a couple of weeks awaiting for some form of stabilization
>  of the new module code (don't blame me - I can only, ahem, "test" on
>  my work laptop), and I had forgot about smsc-ircc2.
> 
> Since it seems someone could make some of the modular stuff work
>  I'm back in the game :)
> 
> --alessandro

	Hum... Looks like a weird interaction between smc-ircc and
irport, or allocation failure. Please activate IrDA debug, set it to
level 1 (echo 1 >> /proc/sys/net/irda/debug) and send the new kernel
log.
	Thanks...

	Jean

^ permalink raw reply

* Re: Reliable hardware
From: Patrick Finnegan @ 2002-12-11 23:35 UTC (permalink / raw)
  To: Alan Cox; +Cc: Orion Poplawski, scott, Linux Kernel Mailing List
In-Reply-To: <1039626108.17702.64.camel@irongate.swansea.linux.org.uk>

On 11 Dec 2002, Alan Cox wrote:

> On Wed, 2002-12-11 at 16:08, Orion Poplawski wrote:
> > Is there a good site for pointers towards assembling reliable Linux
> > machines?  It seems to me the trickiest part of the whole operation is
> > choosing good hardware in the first place.  I just started a new job and
> > inherited a buch of new but flakey machines, and I'd like to avoid doing
> > that in the future.
>
> The AMD duals have been a disaster in my experience. Its a shame because
> when they do go they really are very fast boxes. The biggest factor I've
> found is chipsets.

Which chipset - the new or the old one?  I've got an ASUS A7M266D (or
something) that's based on the AMD 760MPX chipset and has 512MB of
Registered ECC memory, and a pair of XP 1800+'s... and it works just
beautifuly.  Truely rock solid.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu



^ permalink raw reply

* kernel for 405 w/ FPU available
From: Mark Pilon @ 2002-12-11 23:27 UTC (permalink / raw)
  To: linuxppc-embedded


I've finished the initial work to support the IBM 405pm
[405 core, larger caches, FPU] and was wondering if anyone
wants it integrated into the _devel tree.

I worked out of the 2.4 _devel rsync tree (2.4.20-rc2) as I wasn't
able to get my bitkeeper snapshot to compile for walnut.

High level view of the changes:

config.in changes to set a cpu type of 405pm,

FPU unavailable exception, load_up_fpu(), giveup_fpu(),

additions to the ibm ethernet code to support the multiplexed
mal ints on the 405pm,

bits & pieces to tie it all together, and a hack or 2 which ought
to be reworked.

Missing:
no PCI, DMA or IDE support yet.

send me email if The Powers That Be want this stuff.  It has been
stress tested with a mix of fpu tasks and handling a ping flood.


Mark

--
Mark Pilon
Minolta-QMS

P.O. Box 37
325 Dawson County Road 227
Fallon, MT.  59326-0037
1-406-486-5539 (primary voice line)
1-406-853-0433 (cell)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* RE: Filter by IP address problems
From: Stewart Thompson @ 2002-12-11 23:26 UTC (permalink / raw)
  To: Damon Brinkley, netfilter
In-Reply-To: <1039642859.4340.14.camel@damon.betcolan>

Hi Damon:

	Iptables is different than Ipchains. The forwarded
Packets do not go through the Input or Output chains. If
you want to deny certain packets from being forwarded,
you have to put your deny rule in the forward chains.
Have a look at the documentation at www.netfilter.org.
They show a diagram there of the packet traversal.
Hope that helps.

Stu.......


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Damon Brinkley
Sent: December 11, 2002 1:41 PM
To: netfilter@lists.netfilter.org
Subject: Filter by IP address problems

Hey everyone!  I'm getting extremely frustrated at iptables right now
because it doesn't seem to follow the rules as ipchains did.  Basically
I'm just trying to replace my ipchains server with a new computer that
uses 2.4 and iptables.  This is a NAT/gateway machine and we filter our
users by IP addresses.  The different ip blocks have certain access to
certain services.  I've copied over my old script that's running right
now and changed everything to work with iptables but it doesn't seem to
deny anyone.

Here's the basic rules I have right now for testing.

###################################

# disable ip forwarding while rules are applied
echo 0 > /proc/sys/net/ipv4/ip_forward

/sbin/modprobe iptable_nat
/sbin/modprobe ip_conntrack

/sbin/iptables -F
/sbin/iptables -t nat -F
/sbin/iptables -X
/sbin/iptables -t nat -X

/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP

# no access
/sbin/iptables -A INPUT -s 172.17.0.0/20 -j DROP

# NAT
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -j ACCEPT

# turn on ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

####################

If I change my laptop IP to 172.17.0.244 then I'm able to ping
www.yahoo.com when the no access rule should deny then from doing
anything.  This is all working on a machine that uses ipchains...what am
I doing wrong?

Thanks
Damon Brinkley




^ permalink raw reply

* Re: [Linux-ia64] fpswa logging redux
From: Jesse Barnes @ 2002-12-11 23:26 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805545@msgid-missing>

On Thu, Dec 12, 2002 at 10:17:20AM +1100, Keith Owens wrote:
> On Wed, 11 Dec 2002 15:12:18 -0800, 
> Jesse Barnes <jbarnes@sgi.com> wrote:
> >On Thu, Dec 12, 2002 at 10:07:57AM +1100, Keith Owens wrote:
> >> I have a couple of Perl scripts for decoding isr and psr.  They read
> >> hex values (with or without the leading 0x) from stdin and pretty print
> >> the result.
> >
> >It's the isr code field I'm particularly interested in.  For fp faults
> >and traps, I'd like to decode what type of fault/trap occured and add it
> >to the printk, e.g.
> >Dec 11 17:11:05 morale kernel: a.out(1901): floating-point assist trap : ip@00000000000752
> >Dec 11 17:11:05 morale kernel: a.out(1901): floating-point assist fault : software assist ip@00000000000c01
> 
> The general approach is that the kernel prints raw values and user
> space decodes them, unless there is some overriding reason to do it in
> kernel.  IOW, print the isr in the kernel but decode it using the
> scripts or equivalent.

But if we do that the si_code field of siginfo won't have useful
information.  My thought was that if we decode isr in enough detail to
fill in si_code correctly, we may as well make the printks more useful
as well.  I think all this stuff would be in arch/ia64/kernel/traps.c,
with the possible exception of another SIGFPE code for software assist
faults (and maybe denormal/unnormal).

Thanks,
Jesse


^ permalink raw reply

* linux-mips fbdev
From: nsauzede @ 2002-12-11 23:24 UTC (permalink / raw)
  To: linux-mips

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

Hi list !

I've got an Indy running linux-mips and I wonder if fbdev exists/is possible on this platform.
If I remember well, direct framebuffer mmaping like on intel platforms for example is not possible because Video Ram is hidden behind SGI custom video chips, and video accesses are done by some magic incantations..

But the fact is that I can run linux on my box, a gfx penguin logo appears at boot, and I can enjoy a huge beautifull mc on the console, so I guess some "kind" of framebuffer is there, but not the full-blown Geert's-et-al stuff.

So my question is : would it be feasible/easy to implement some kind of "stubs" to, at least, simulate a straight framebuffer, with full /dev/fb0 stuff, so I could port my fbdev userspace stuff to my Indy ???

Sorry if the answer is obvious..

Thanks so much to all of you linux-mips-gurus for what has been done !!

Nicolas Sauzede.

ps : in case the answer is : No; would it be hard for newbies like me to enable userspace apps to access video screen (just like with fbdev, but without it), ie : be able to do some bitblt() or such ? I've tried to copy/paste some kernel fragments that "seems" to do the voodoo-like video accesses, just to set some pixels on screen, but all I could obtain was : entire screen corrupted or even crash (no BSOD here though <whew> ;)


[-- Attachment #2: Type: text/html, Size: 2410 bytes --]

^ permalink raw reply

* HyperThreading in recent 2.4-ac kernels
From: Gerald Britton @ 2002-12-11 23:30 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel
In-Reply-To: <200212112043.gBBKhLE28272@devserv.devel.redhat.com>

HyperThreading appears to work properly in vanilla 2.4.x, but fails to
initialize the sibling CPUs in 2.4.x-ac.  The problem appears to be in
improper indexing by physical vs. logical CPU numbers.

in smpboot.c (in smp_boot_cpus):

        Dprintk("CPU present map: %lx\n", phys_cpu_present_map);
        cpu = 1;
        for (bit = 0; bit < NR_CPUS; bit++) {
                ...
                phys_apicid = raw_phys_apicid[bit];
                ...
                if ((cpu_to_physical_apicid(bit) == BAD_APICID) &&
                ...

in mpparse.c (in MP_processor_info):

        raw_phys_apicid[num_processors - 1] = m->mpc_apicid;

Booting with HT and some debugging enabled yields:

...
LAPIC (acpi_id[0x0000] id[0x0] enabled[1])
CPU 0 (0x0000) enabledProcessor #0 Pentium 4(tm) XEON(tm) APIC version 16
LAPIC (acpi_id[0x0001] id[0x6] enabled[1])
CPU 1 (0x0600) enabledProcessor #6 Pentium 4(tm) XEON(tm) APIC version 16
LAPIC (acpi_id[0x0002] id[0x1] enabled[1])
CPU 2 (0x0100) enabledProcessor #1 Pentium 4(tm) XEON(tm) APIC version 16
LAPIC (acpi_id[0x0003] id[0x7] enabled[1])
CPU 3 (0x0700) enabledProcessor #7 Pentium 4(tm) XEON(tm) APIC version 16
...
CPU present map: c3
...

The processors appear to have physical IDs 0, 1, 6, 7.  raw_phys_apicid[] gets
filled at indexes 0-4, but when the kernel tries to boot the CPUs, it queries
it with physical indexes 0, 1, 6, 7 and loses.  I'm not sure exactly what the
correct way to fix this is.  (a quick hack to raw_phys_apicid does get all 4
CPUs up and apparently working though)

There appear to be other areas where holes in the physical IDs will cause
problems (things fill indexes by a logical cpu number and index later by
physical ID, or the other way around).

Example: following booting a cpu, the check to see if it booted checks
cpu_to_physical_apicid(bit) where bit is the physical cpu id in the map, but
the table it's checking is indexed by logical cpu number.

				-- Gerald


^ permalink raw reply

* Compilation problems with local APIC for uniprocessors in linux 2.4.20-ac2
From: system_lists @ 2002-12-11 23:27 UTC (permalink / raw)
  To: linux-kernel


I got:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-ac2/include 
-I/usr/lib/gcc-lib/i386-linux/3.2.2/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer 
-pipe -mpreferred-stack-boundary=2 -march=i686   -nostdinc -iwithprefix 
include -DKBUILD_BASENAME=mpparse  -c -o mpparse.o mpparse.c
mpparse.c:75: `dest_LowestPrio' undeclared here (not in a function)
mpparse.c: In function `smp_read_mpc':
mpparse.c:607: `dest_Fixed' undeclared (first use in this function)
mpparse.c:607: (Each undeclared identifier is reported only once
mpparse.c:607: for each function it appears in.)
mpparse.c:607: `dest_LowestPrio' undeclared (first use in this function)
make[1]: *** [mpparse.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.20-ac2/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2


the variable is not defined or is not "inherited".

Seeya


^ permalink raw reply

* Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues
From: Carlos O'Donell @ 2002-12-11 23:17 UTC (permalink / raw)
  To: John David Anglin; +Cc: parisc-linux
In-Reply-To: <200212112305.gBBN5Bdj021432@hiauly1.hia.nrc.ca>

> The code doesn't seem to trap on a A500 which I believe is a PA8500.

Could be a PA8600 too.

> I think we need to look at bits 0..1 of the coprocessor configuration
> register to determine instruction validity.  See table 8-6 on page 8-11.
> I can look at what the HP compiler does.  Up to now, we have assumed
> that all PA8000 machines have the same instruction set.

I'm building a new kernel right now to run the test on again.
My sociology exam is in a half-hour... I need a little break ;)

c.

^ permalink raw reply

* Re: [Linux-ia64] fpswa logging redux
From: Keith Owens @ 2002-12-11 23:17 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805545@msgid-missing>

On Wed, 11 Dec 2002 15:12:18 -0800, 
Jesse Barnes <jbarnes@sgi.com> wrote:
>On Thu, Dec 12, 2002 at 10:07:57AM +1100, Keith Owens wrote:
>> I have a couple of Perl scripts for decoding isr and psr.  They read
>> hex values (with or without the leading 0x) from stdin and pretty print
>> the result.
>
>It's the isr code field I'm particularly interested in.  For fp faults
>and traps, I'd like to decode what type of fault/trap occured and add it
>to the printk, e.g.
>Dec 11 17:11:05 morale kernel: a.out(1901): floating-point assist trap : ip@00000000000752
>Dec 11 17:11:05 morale kernel: a.out(1901): floating-point assist fault : software assist ip@00000000000c01

The general approach is that the kernel prints raw values and user
space decodes them, unless there is some overriding reason to do it in
kernel.  IOW, print the isr in the kernel but decode it using the
scripts or equivalent.



^ permalink raw reply

* Re: [parisc-linux] another kernel compilation error
From: Tim Kemna @ 2002-12-11 23:09 UTC (permalink / raw)
  To: Paul Bame; +Cc: parisc-linux
In-Reply-To: <20021211165410.EAD7015192@paul.bame>

> > drivers/char/char.o: In function `hp_diva_check':
> > drivers/char/char.o(.text.hp_diva_check+0x60): undefined reference to
> > `rs_interrupt'
> > make: *** [vmlinux] Error 1
> > 
> > What am I doing wrong?
> 
> Probably nothing but I did :-)  My Diva changes currently require
> CONFIG_SERIAL_SHARE_IRQ to be set -- need to fix that.

I can't find that option in my .config

^ permalink raw reply

* Re: [Linux-ia64] fpswa logging redux
From: Jesse Barnes @ 2002-12-11 23:12 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805545@msgid-missing>

On Thu, Dec 12, 2002 at 10:07:57AM +1100, Keith Owens wrote:
> I have a couple of Perl scripts for decoding isr and psr.  They read
> hex values (with or without the leading 0x) from stdin and pretty print
> the result.

It's the isr code field I'm particularly interested in.  For fp faults
and traps, I'd like to decode what type of fault/trap occured and add it
to the printk, e.g.
Dec 11 17:11:05 morale kernel: a.out(1901): floating-point assist trap : ip@00000000000752
Dec 11 17:11:05 morale kernel: a.out(1901): floating-point assist fault : software assist ip@00000000000c01

Jesse


^ permalink raw reply

* Re: Kill TRUE/FALSE from hp100.c
From: Pavel Machek @ 2002-12-11 23:15 UTC (permalink / raw)
  To: Jirka Kosina; +Cc: Christoph Hellwig, Pavel Machek, kernel list
In-Reply-To: <Pine.LNX.4.50.0212120003480.5642-100000@twin.jikos.cz>

Hi!

> > > Kernel coding style does not like TRUE/FALSE, AFAICS. Please apply,
> > What's even more interesting:  were did the defintions of TRUE/FALSE
> > as used by hp100.c come from?
> 
> AFAIK drivers/net/hp100.h
> 
> Should probably be also removed.
> 
> Quick grepping in drviers/ showed many places, where TRUE/FALSE semantics
> is also used...probably should be removed too, shouldn't it?

Yes... I killed these because they hurt my eyes; I don't have to deal
with others so I'm unlike to go and kill them.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

^ permalink raw reply

* Re: [Linux-ia64] fpswa logging redux
From: Keith Owens @ 2002-12-11 23:07 UTC (permalink / raw)
  To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805545@msgid-missing>

On Wed, 11 Dec 2002 14:25:14 -0800, 
Jesse Barnes <jbarnes@sgi.com> wrote:
>I've recently had some requests from people running apps on our ia64
>boxes for more detailed fpswa fault information.  Currently, the ia64
>kernel will print up to a certain number of fpswa fault messages per
>tick, with ip information about where the fault came from.  The user can
>also choose to be notified of faults via a SIGFPE signal, but the
>si_info field of the siginfo structure doesn't contain enough
>information about the fault to be useful.
>
>I'd like to fully decode the information in the isr about what type of
>fault occured (whether it be a software assist fault, some sort of IEEE
>filter fault, etc.) and print it along with the ip when faults occur.
>While I'm at it, I may as well the proper SIGFPE subcode into si_info in
>case of signal delivery is selected.

I have a couple of Perl scripts for decoding isr and psr.  They read
hex values (with or without the leading 0x) from stdin and pretty print
the result.

--- ia64_isr ---

#!/usr/bin/perl -w
use strict;
use integer;

my @fields = (
	[ 0, 16, "Code" ],
	[ 16, 8, "Vector" ],
	[ 24, 8, "rv" ],
	[ 32, 1, "x" ],
	[ 33, 1, "w" ],
	[ 34, 1, "r" ],
	[ 35, 1, "na" ],
	[ 36, 1, "sp" ],
	[ 37, 1, "rs" ],
	[ 39, 1, "ni" ],
	[ 40, 1, "so" ],
	[ 41, 2, "ei" ],
	[ 43, 1, "ed" ],
	[ 44, 20, "rv" ],
	);

while (defined($_ = <STDIN>)) {
	chomp();
	s/^0[xX]//;
	my $w0 = hex(substr($_, 0, -8));
	my $w1 = hex(substr($_, -8));
	printf("isr %s\n", $_);
	&ia64_isr($w1, 0, 32);
	&ia64_isr($w0, 32, 64);
}

sub ia64_isr()
{
	my ($w, $s, $e) = @_;
	my $v;
	foreach (@fields) {
		next if ($_->[0] >= $e || $_->[0] < $s);
		# use integer implies signed shift, I want unsigned
		no integer;
		$v = ($w >> ($_->[0] - $s)) & (~0 >> (32 - $_->[1]));
		printf("%2d %2d %12s %x\n", $_->[0], $_->[1], $_->[2], $v);
	}
}

--- ia64_psr ---

#!/usr/bin/perl -w
use strict;
use integer;

my @fields = (
	[ 0, 6, "User mask" ],
	[ 0, 1, "rv" ],
	[ 1, 1, "be" ],
	[ 2, 1, "up" ],
	[ 3, 1, "ac" ],
	[ 4, 1, "mfl" ],
	[ 5, 1, "mfh" ],
	[ 0, 24, "System mask" ],
	[ 6, 6, "rv" ],
	[ 13, 1, "ic" ],
	[ 14, 1, "i" ],
	[ 15, 1, "pk" ],
	[ 16, 1, "rv" ],
	[ 17, 1, "dt" ],
	[ 18, 1, "dfl" ],
	[ 19, 1, "dfh" ],
	[ 20, 1, "sp" ],
	[ 21, 1, "pp" ],
	[ 22, 1, "di" ],
	[ 23, 1, "si" ],
	[ 24, 1, "db" ],
	[ 25, 1, "lp" ],
	[ 26, 1, "tb" ],
	[ 27, 1, "rt" ],
	[ 28, 4, "rv" ],
	[ 32, 2, "cpl" ],
	[ 34, 1, "is" ],
	[ 35, 1, "mc" ],
	[ 36, 1, "it" ],
	[ 37, 1, "id" ],
	[ 38, 1, "da" ],
	[ 39, 1, "dd" ],
	[ 40, 1, "ss" ],
	[ 41, 2, "ri" ],
	[ 43, 1, "ed" ],
	[ 44, 1, "bn" ],
	[ 45, 1, "ia" ],
	[ 46, 18, "rv" ]
	);

while (defined($_ = <STDIN>)) {
	chomp();
	s/^0[xX]//;
	my $w0 = hex(substr($_, 0, -8));
	my $w1 = hex(substr($_, -8));
	printf("psr %s\n", $_);
	&ia64_psr($w1, 0, 32);
	&ia64_psr($w0, 32, 64);
}

sub ia64_psr()
{
	my ($w, $s, $e) = @_;
	my $v;
	foreach (@fields) {
		next if ($_->[0] >= $e || $_->[0] < $s);
		# use integer implies signed shift, I want unsigned
		no integer;
		$v = ($w >> ($_->[0] - $s)) & (~0 >> (32 - $_->[1]));
		printf("%2d %2d %12s %x\n", $_->[0], $_->[1], $_->[2], $v);
	}
}



^ permalink raw reply

* Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues
From: John David Anglin @ 2002-12-11 23:05 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: bdale, parisc-linux
In-Reply-To: <20021211224404.GC15219@systemhalted>

> The code _seems_ to trap on a PA8600. Though I won't say anything until
> I enable debugging in the trap handler and rerun the test.

The code doesn't seem to trap on a A500 which I believe is a PA8500.
I think we need to look at bits 0..1 of the coprocessor configuration
register to determine instruction validity.  See table 8-6 on page 8-11.
I can look at what the HP compiler does.  Up to now, we have assumed
that all PA8000 machines have the same instruction set.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

^ permalink raw reply

* Re: Strange load spikes on 2.4.19 kernel
From: Andrew Morton @ 2002-12-11 23:09 UTC (permalink / raw)
  To: Steven Roussey; +Cc: robm, linux-kernel
In-Reply-To: <000b01c2a168$37e747d0$026fa8c0@wehohome>

Steven Roussey wrote:
> 
> Was there ever a solution to this issue?

No.  It wasn't clear what was going on.

>  Is it kernel or ext3 based issue?

One of those.

> Is there a workaround?

Tried mounting all filesystems `-o noatime'?

> I've spent two months looking for a source and
> solution to this issue. It is pressing for me since all our users get locked
> out at the height of the spike. Ours is a webserver.
> 

Is there much disk write activity?  What journalling mode
are you using?

The output of `ps aux' during a stall would be interesting,
as would the `vmstat 1' ouptut.

^ permalink raw reply

* [linux-lvm] vgcreate on md: vgcreate -- ERROR "pv_read(): read" reading physical volumes
From: udo @ 2002-12-11 23:01 UTC (permalink / raw)
  To: linux-lvm

Hello,

LVM worked OK on my small machine so I wanted to
implement LVM for my /usr, /var and /home.
The box has 2 identical 20G IBM IDE disks and is
running 2.4.20 (LVM 1.05).
Partitions:

Disk /dev/hda: 255 heads, 63 sectors, 2501 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id 
System
/dev/hda1             1         3     24066   fd 
Linux raid autodetect
/dev/hda2             4      2501  20065185    5 
Extended
/dev/hda5             4        23    160618+  fd 
Linux raid autodetect
/dev/hda6            24      2450  19494846   fd 
Linux raid autodetect
/dev/hda7          2451      2465    120456   82 
Linux swap
/dev/hda8          2466      2501    289138+  83 
Linux

I have /boot on /dev/md0, / on /dev/md1 and want the
LVM on /dev/md2 (/dev/hda6 and /dev/hdc6) so I did
vgcreate vg00 /dev/md2 which gives:
vgcreate -- ERROR "pv_read(): read" reading physical
volumes

I couldn't find too much info about this problem in
connection with md. :-/

Please let me know how I can fix this.
The debug output is below:

<1> vg_check_name -- CALLED with VG: vg00
<22> lvm_check_chars -- CALLED with name: "vg00"
<22> lvm_check_chars -- LEAVING with ret: 0
<1> vg_check_name -- LEAVING with ret: 0
<1> vg_check_dir -- CALLED with VG: vg00
<22> vg_check_name -- CALLED with VG: vg00
<333> lvm_check_chars -- CALLED with name: "vg00"
<333> lvm_check_chars -- LEAVING with ret: 0
<22> vg_check_name -- LEAVING with ret: 0
<1> vg_check_dir -- vg_name: "vg00"
<1> vg_check_dir -- LEAVING with ret: 0
<1> lvm_lock -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_lock -- LEAVING with ret: 0
<1> lvm_get_iop_version -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_get_iop_version -- AFTER ioctl ret: 0
<1> lvm_get_iop_version -- LEAVING with ret: 10
<1> lvm_tab_vg_check_exist -- CALLED with vg_name:
"vg00"
<22> vg_check_name -- CALLED with VG: vg00
<333> lvm_check_chars -- CALLED with name: "vg00"
<333> lvm_check_chars -- LEAVING with ret: 0
<22> vg_check_name -- LEAVING with ret: 0
<22> lvm_tab_read -- CALLED
<22> lvm_tab_read -- LEAVING with ret: 0  data:
804C1F8  size: 1
<1> lvm_tab_vg_check_exist -- LEAVING with ret: 0
<1> lvm_tab_vg_check_exist_all_vg -- CALLED
<22> lvm_tab_read -- CALLED
<22> lvm_tab_read -- LEAVING with ret: 0  data:
804C1F8  size: 1
<1> lvm_tab_vg_check_exist_all_vg -- LEAVING with ret:
0
<1> pv_read_all_pv -- CALLED
<1> pv_read_all_pv -- calling lvm_dir_cache
<22> lvm_dir_cache -- CALLED
<333> lvm_add_dir_cache -- CALLED with /dev/md0
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 2
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/md1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 2
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/md2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 2
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc5
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc6
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc7
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hdc8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda5
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda6
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda7
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/hda8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop0
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop10
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop11
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop12
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop13
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop14
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop15
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop3
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop4
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop5
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop6
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop7
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<333> lvm_add_dir_cache -- CALLED with /dev/loop9
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 3
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> lvm_add_dir_cache -- LEAVING with ret: NOT ADDED
<22> lvm_dir_cache -- LEAVING with ret: 25
<1> pv_read_all_pv -- calling stat with "/dev/md0"
<22> pv_read -- CALLED with /dev/md0
<333> pv_check_name -- CALLED with "/dev/md0"
<4444> lvm_check_chars -- CALLED with name: "/dev/md0"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/md0
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 2
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804cc80
<333> pv_create_name_from_kdev_t -- CALLED with 9:0
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 2
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/md0
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/md1"
<22> pv_read -- CALLED with /dev/md1
<333> pv_check_name -- CALLED with "/dev/md1"
<4444> lvm_check_chars -- CALLED with name: "/dev/md1"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/md1
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 2
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804ce88
<333> pv_create_name_from_kdev_t -- CALLED with 9:1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 2
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/md1
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/md2"
<22> pv_read -- CALLED with /dev/md2
<333> pv_check_name -- CALLED with "/dev/md2"
<4444> lvm_check_chars -- CALLED with name: "/dev/md2"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/md2
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 2
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804d090
<333> pv_create_name_from_kdev_t -- CALLED with 9:2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 2
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
FALSE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/md2
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc"
<22> pv_read -- CALLED with /dev/hdc
<333> pv_check_name -- CALLED with "/dev/hdc"
<4444> lvm_check_chars -- CALLED with name: "/dev/hdc"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804d298
<333> pv_create_name_from_kdev_t -- CALLED with 22:0
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc1"
<22> pv_read -- CALLED with /dev/hdc1
<333> pv_check_name -- CALLED with "/dev/hdc1"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hdc1"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc1
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804d4a0
<333> pv_create_name_from_kdev_t -- CALLED with 22:1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc1
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc2"
<22> pv_read -- CALLED with /dev/hdc2
<333> pv_check_name -- CALLED with "/dev/hdc2"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hdc2"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc2
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804d6a8
<333> pv_create_name_from_kdev_t -- CALLED with 22:2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc2
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc5"
<22> pv_read -- CALLED with /dev/hdc5
<333> pv_check_name -- CALLED with "/dev/hdc5"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hdc5"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc5
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804d8b0
<333> pv_create_name_from_kdev_t -- CALLED with 22:5
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc5
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc6"
<22> pv_read -- CALLED with /dev/hdc6
<333> pv_check_name -- CALLED with "/dev/hdc6"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hdc6"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc6
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804dab8
<333> pv_create_name_from_kdev_t -- CALLED with 22:6
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc6
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc7"
<22> pv_read -- CALLED with /dev/hdc7
<333> pv_check_name -- CALLED with "/dev/hdc7"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hdc7"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc7
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804dcc0
<333> pv_create_name_from_kdev_t -- CALLED with 22:7
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc7
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hdc8"
<22> pv_read -- CALLED with /dev/hdc8
<333> pv_check_name -- CALLED with "/dev/hdc8"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hdc8"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hdc8
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804dec8
<333> pv_create_name_from_kdev_t -- CALLED with 22:8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hdc8
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda"
<22> pv_read -- CALLED with /dev/hda
<333> pv_check_name -- CALLED with "/dev/hda"
<4444> lvm_check_chars -- CALLED with name: "/dev/hda"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804e0d0
<333> pv_create_name_from_kdev_t -- CALLED with 3:0
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda1"
<22> pv_read -- CALLED with /dev/hda1
<333> pv_check_name -- CALLED with "/dev/hda1"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hda1"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda1
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804e2d8
<333> pv_create_name_from_kdev_t -- CALLED with 3:1
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda1
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda2"
<22> pv_read -- CALLED with /dev/hda2
<333> pv_check_name -- CALLED with "/dev/hda2"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hda2"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda2
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804e4e0
<333> pv_create_name_from_kdev_t -- CALLED with 3:2
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda2
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda5"
<22> pv_read -- CALLED with /dev/hda5
<333> pv_check_name -- CALLED with "/dev/hda5"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hda5"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda5
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804e6e8
<333> pv_create_name_from_kdev_t -- CALLED with 3:5
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda5
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda6"
<22> pv_read -- CALLED with /dev/hda6
<333> pv_check_name -- CALLED with "/dev/hda6"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hda6"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda6
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804e8f0
<333> pv_create_name_from_kdev_t -- CALLED with 3:6
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda6
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda7"
<22> pv_read -- CALLED with /dev/hda7
<333> pv_check_name -- CALLED with "/dev/hda7"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hda7"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda7
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804eaf8
<333> pv_create_name_from_kdev_t -- CALLED with 3:7
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda7
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/hda8"
<22> pv_read -- CALLED with /dev/hda8
<333> pv_check_name -- CALLED with "/dev/hda8"
<4444> lvm_check_chars -- CALLED with name:
"/dev/hda8"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/hda8
<333> lvm_check_dev -- CALLED
<4444> lvm_check_partitioned_dev -- CALLED
<55555> lvm_get_device_type called
<55555> lvm_get_device_type leaving with 0
<4444> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<333> lvm_check_dev -- LEAVING with ret: 1
<333> pv_copy_from_disk -- CALLED
<333> pv_copy_from_disk -- LEAVING ret = 0x804ed00
<333> pv_create_name_from_kdev_t -- CALLED with 3:8
<4444> lvm_check_dev -- CALLED
<55555> lvm_check_partitioned_dev -- CALLED
<666666> lvm_get_device_type called
<666666> lvm_get_device_type leaving with 0
<55555> lvm_check_partitioned_dev -- LEAVING with ret:
TRUE
<4444> lvm_check_dev -- LEAVING with ret: 1
<4444> lvm_dir_cache -- CALLED
<4444> lvm_dir_cache -- LEAVING with ret: 25
<333> pv_create_name_from_kdev_t -- LEAVING with
dev_name: /dev/hda8
<22> pv_read -- LEAVING with ret: -268
<1> pv_read_all_pv -- pv_read returned: -268
<1> pv_read_all_pv -- calling stat with "/dev/loop0"
<22> pv_read -- CALLED with /dev/loop0
<333> pv_check_name -- CALLED with "/dev/loop0"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop0"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop0
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop1"
<22> pv_read -- CALLED with /dev/loop1
<333> pv_check_name -- CALLED with "/dev/loop1"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop1"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop1
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop2"
<22> pv_read -- CALLED with /dev/loop2
<333> pv_check_name -- CALLED with "/dev/loop2"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop2"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop2
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop3"
<22> pv_read -- CALLED with /dev/loop3
<333> pv_check_name -- CALLED with "/dev/loop3"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop3"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop3
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop4"
<22> pv_read -- CALLED with /dev/loop4
<333> pv_check_name -- CALLED with "/dev/loop4"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop4"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop4
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop5"
<22> pv_read -- CALLED with /dev/loop5
<333> pv_check_name -- CALLED with "/dev/loop5"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop5"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop5
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop6"
<22> pv_read -- CALLED with /dev/loop6
<333> pv_check_name -- CALLED with "/dev/loop6"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop6"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop6
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- calling stat with "/dev/loop7"
<22> pv_read -- CALLED with /dev/loop7
<333> pv_check_name -- CALLED with "/dev/loop7"
<4444> lvm_check_chars -- CALLED with name:
"/dev/loop7"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> pv_check_name -- LEAVING with ret: 0
<22> pv_read -- going to read /dev/loop7
<22> pv_read -- LEAVING with ret: -282
<1> pv_read_all_pv -- pv_read returned: -282
<1> pv_read_all_pv -- avoiding multiple entries in
case of MD; np: 0
<1> pv_read_all_pv -- LEAVING with ret: -282
<1> lvm_error -- CALLED with: -282
<1> lvm_error -- LEAVING with: "pv_read(): read"
vgcreate -- ERROR "pv_read(): read" reading physical
volumes

<1> lvm_unlock -- CALLED
<1> lvm_unlock -- LEAVING with ret: 0


Kid regards,
Udo

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

^ permalink raw reply

* Re: Kill TRUE/FALSE from hp100.c
From: Jirka Kosina @ 2002-12-11 23:08 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Pavel Machek, kernel list
In-Reply-To: <20021211224734.A7023@infradead.org>

On Wed, 11 Dec 2002, Christoph Hellwig wrote:

> > Kernel coding style does not like TRUE/FALSE, AFAICS. Please apply,
> What's even more interesting:  were did the defintions of TRUE/FALSE
> as used by hp100.c come from?

AFAIK drivers/net/hp100.h

Should probably be also removed.

Quick grepping in drviers/ showed many places, where TRUE/FALSE semantics
is also used...probably should be removed too, shouldn't it?

--
JiKos.


^ permalink raw reply

* [U-Boot-Users] Looking for ARM9E u-boot/linux platform - recommendations?
From: Wolfgang Denk @ 2002-12-11 22:58 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <20021211212708.GA19189@zumanetworks.com>

In message <20021211212708.GA19189@zumanetworks.com> you wrote:
> 
> I am working on an embedded linux ARM9E based project and i'm looking
> for a good eval board to get my feet wet... any suggestions?

The only ARM9TDMI systems directly supported by U-Boot are SMDK2400 /
SMDK2410 (Samsung Developmnt kits using s3c2400 / s3c2410 processors)
and TRAB (a proprietary board pretty similar to the SMDK2400  as  far
as U-Boot is concerned).

We have the SMDK2400 and TRAB in our compile farm.

> 1) MMU/cache/SDRAM support/stability (most important)

Check.

> 2) availability (preferably US mfg'r)

Don't know.

> 3) linux/u-boot stability

Check.

> 4) cost

Don't know.

> 5) performance (least important)

Not bad.


> Hi Wolfgang! Moving to another project name will not get rid of me
> so easily, muahahaha ;)

You are most welcome.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"There are three principal ways to lose money: wine, women, and engi-
neers. While the first two are more pleasant, the third is by far the
more certain."                           - Baron Rothschild, ca. 1800

^ permalink raw reply

* IDE PCMCIA badness
From: Stian Jordet @ 2002-12-11 23:05 UTC (permalink / raw)
  To: Linux Kernel Mailing List

Hi, is this normal? I know unmount of ide-pcmcia devices don't work. The
device works perfect, but I get this message upon boot:

hde: PCMCIA/SD ADAPTER, CFA DISK drive
ide2 at 0x100-0x107,0x10e on irq 19
hde: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hde: task_no_data_intr: error=0x04 { DriveStatusError }
hde: 62720 sectors (32 MB) w/1KiB Cache, CHS=490/4/32
 hde: hde1
 hde: hde1
Badness in kobject_register at lib/kobject.c:113
Call Trace: [<c01e9b05>]  [<c017368c>]  [<c01737e9>]  [<c022f6de>] 
[<c022f624>]  [<c022f62c>]  [<c025eea8>]  [<c02642be>]  [<c026077d>] 
[<c025a9c6>]  [<c025f2fe>]  [<c025fd67>]  [<c0267b62>]  [<c011f51b>] 
[<c026806a>]  [<c02a04d3>]  [<c0298300>]  [<c02984bb>]  [<c0298a32>] 
[<c0299125>]  [<c029a257>]  [<c029a361>]  [<c0115cb5>]  [<c02a0f69>] 
[<c0298f43>]  [<c0298d39>]  [<c02984bb>]  [<c029a322>]  [<c02a0f69>] 
[<c02a04d3>]  [<c0298300>]  [<c02984bb>]  [<c0298a32>]  [<c0299125>] 
[<c029a257>]  [<c029a361>]  [<c0115cb5>]  [<c02a0f69>]  [<c0298f43>] 
[<c0298d39>]  [<c02984bb>]  [<c029a322>]  [<c0298a32>]  [<c0298f1b>] 
[<c0298f43>]  [<c029a4a2>]  [<c01846f7>]  [<c014495b>]  [<c01846f7>] 
[<c018a7b2>]  [<c018475d>]  [<c0184d9d>]  [<c017bbff>]  [<c0268290>] 
[<c029d829>]  [<c010ab21>]  [<c010ab4f>]  [<c029e9ce>]  [<c0267a57>] 
[<c0268214>]  [<c029f797>]  [<c029f7d9>]  [<c02a01cd>]  [<c03043a8>] 
[<c012fdae>]  [<c012fe39>]  [<c0138320>]  [<c0138388>]  [<c0138681>] 
[<c0115782>]  [<c0130363>]  [<c01300db>]  [<c0133d25>]  [<c013709d>] 
[<c01370fd>]  [<c013f972>]  [<c013a10a>]  [<c0139fa5>]  [<c0139fc0>] 
[<c013a377>]  [<c0154069>]  [<c0108b83>] 
ide-cs: hde: Vcc = 3.3, Vpp = 0.0
 hde: hde1


Btw, why does it write _three_ times hde: hde1? It does this with 2.4 as
well.

Best regards,
Stian Jordet


^ permalink raw reply

* Re: Kill TRUE/FALSE from hp100.c
From: Pavel Machek @ 2002-12-11 23:04 UTC (permalink / raw)
  To: Christoph Hellwig, Rusty trivial patch monkey Russell,
	kernel list, jgarzik
In-Reply-To: <20021211224734.A7023@infradead.org>

Hi!

> > Kernel coding style does not like TRUE/FALSE, AFAICS. Please apply,
> 
> What's even more interesting:  were did the defintions of TRUE/FALSE
> as used by hp100.c come from?

hp100.h. I did not yet kill them but will do that soon.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

^ permalink raw reply


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.