* help. a question on "make menuconfig"
From: Ming Liu @ 2006-04-05 16:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am a novice for embendded linux. My platform is Xilinx Virtex4 (PPC405).
I have downloaded the kernal source of linuxppc_2_4_devel and modified the
Makefile as:
ARCH := ppc
CROSS_COMPILE = powerpc-405-linux-gnu-
But when I execute "make menuconfig", the following error happens,
mingliu@linux:~/linuxppc_2_4_devel> make menuconfig
make: *** arch/ppc: Is a directory. Stop.
mingliu@linux:~/linuxppc_2_4_devel>
Why this error happened? Is there something wrong with the Makefile? I did
nothing except for specifying the ARCH and the CROSS_COMPILE.
Thanks for your help.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: Compiling xenoprof
From: David Carr @ 2006-04-05 16:19 UTC (permalink / raw)
To: Santos, Jose Renato G; +Cc: xen-devel
In-Reply-To: <6C21311CEE34E049B74CC0EF339464B95849E1@cacexc12.americas.cpqcorp.net>
Renato,
Thanks for your reply. The steps below got the kernels to build. I'm
not sure that everything is quite right yet though. I can profile on
domain 0 and also run opcontrol --reset on the guests. However running
"opcontrol --start" on the guests results in:
Using default event: GLOBAL_POWER_EVENTS:100000:1:1:1
Failed to open profile device: Operation not permitted
Using 2.6+ OProfile kernel interface.
Couldn't start oprofiled.
Check the log file "/var/lib/oprofile/oprofiled.log" and kernel syslog
It appears that this error is coming daemon/liblegacy/init.c or
daemon/init.c
This error only occurs on the guests (which are using the dom0 kernel).
opcontrol --start suceeds on dom0.
Any ideas?
Thanks again,
David Carr
Install steps:
In Xen 3.0.0 source directory:
patch -p1 < xenoprof-2.0-xen-3.0.0.patch
patch -p1 < xenoprof-2.0-linux-2.6-sparse.patch
make kernels
This will ultimately fail. Then do:
In linux-2.6.12-xen0 directory:
patch -p2 < xenoprof-2.0-linux-2.6.12.patch
make kernels
This will ultimately fail. Then do:
In linux-2.6.12-xenU directory:
patch -p2 < xenoprof-2.0-linux-2.6.12.patch
make kernels
This will succeed. Then do:
make dist
sudo make install
In oprofile source directory:
patch -p1 < oprofile-0.9.1-xen.patch
Install oprofile normally
Santos, Jose Renato G wrote:
>
>David,
>
>You are right. This is not very clean.
>Yes, you need to do a "make" to create the xen0 and xenU trees
>before applying the patch in step c).
>If you configure the kernel with oprofile support (CONFIG_OPROFILE)
>before step c) you will probably get a compilation error when
>you run make since the patch was not applied yet. You could either delay
>setting (CONFIG_OPROFILE) for after you apply patch "c" or you
>can apply the patch after you get the compilation error, and then
>run make again.
>
>It would be better if there was a "make" option to create the
>xen0/xenU trees without compiling them. Does anybody know if
>there is such an option? I remember looking for it in the Makefile
>and not finding it, but this was a while ago.
>
>We are now working on getting the xenoprof code included in
>xen-unstable.
>This should make life much easier for those wanting to use oprofile.
>
>Renato
>
>
>
>>>-----Original Message-----
>>>From: xen-devel-bounces@lists.xensource.com
>>>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>>>David Carr
>>>Sent: Tuesday, April 04, 2006 7:31 PM
>>>To: xen-devel@lists.xensource.com
>>>Subject: [Xen-devel] Compiling xenoprof
>>>
>>>I'm having some trouble compiling Xen 3.0.0 with the
>>>xenoprof patches.
>>>
>>>The xenoprof instructions say:
>>>
>>> In order to run OProfile in Xen environments four patches
>>>are needed:
>>> a) xenoprof-2.0-xen-3.0.0.patch
>>> Patch for Xen hypervisor.
>>> b) xenoprof-2.0-linux-2.6-sparse.patch
>>> Patch for Xenolinux. Contains oprofile architecture
>>>specific driver
>>> for xen (Apply to linux-sparse tree in Xen source tree)
>>> c) xenoprof-2.0-linux-2.6.12.patch
>>> Patch for oprofile kernel module in linux 2.6.12.
>>>Contain modifications
>>> to generic oprofile driver code to support xen. (Apply
>>>twice, once to
>>> dom0 and once to domU trees)
>>>
>>>
>>>Every thing goes fine until part c. The linux-2.6.12-xen0
>>>and linux-2.6.12-xenU directories are empty until you build
>>>xen (and therefore can't be patched yet.) Doing a make
>>>world will populate these trees but also compiles everything.
>>>
>>>What is the proper sequence of patching and make commands to
>>>build a xenoprof tree?
>>>
>>>Thanks,
>>>David Carr
>>>
>>>
>>>
>>>_______________________________________________
>>>Xen-devel mailing list
>>>Xen-devel@lists.xensource.com
>>>http://lists.xensource.com/xen-devel
>>>
>>>
>>>
^ permalink raw reply
* [PATCH] powerpc: Fix machine detection in prom_init.c
From: Michael Ellerman @ 2006-04-05 16:18 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In e8222502ee6157e2713da9e0792c21f4ad458d50 the detection of machine types
in prom_init broke for some machines. We should be checking /device_type
instead of /model. This should make Power3 and Power4 boot again. Haven't
been able to test this.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: to-merge/arch/powerpc/kernel/prom_init.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/prom_init.c
+++ to-merge/arch/powerpc/kernel/prom_init.c
@@ -1528,7 +1528,7 @@ static int __init prom_find_machine_type
* non-IBM designs !
* - it has /rtas
*/
- len = prom_getprop(_prom->root, "model",
+ len = prom_getprop(_prom->root, "device_type",
compat, sizeof(compat)-1);
if (len <= 0)
return PLATFORM_GENERIC;
^ permalink raw reply
* Re: [patch 03/26] sysfs: zero terminate sysfs write buffers (CVE-2006-1055)
From: Jon Smirl @ 2006-04-05 16:18 UTC (permalink / raw)
To: Al Viro; +Cc: gregkh, linux-kernel, stable
In-Reply-To: <20060405154629.GJ27946@ftp.linux.org.uk>
On 4/5/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Wed, Apr 05, 2006 at 11:43:15AM -0400, Jon Smirl wrote:
> > > How about _NOT_ using sysfs and just having ->read()/->write() on a file in fs
> ^^^^^^^^^^^^^^^^^
Where does this file come from? A device node?
> > > of your own? ~20 lines for all of it, not counting #include...
> >
> > Sysfs attributes allow full read/write on their file handles. But
> ^^^^^^^^^^^^^^^^
> > GregKH has been discouraging that.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Fix ia64 bit ops: Full barriers for bit operations returning a
From: Christoph Lameter @ 2006-04-05 16:17 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.64.0604031129510.21064@schroedinger.engr.sgi.com>
On Tue, 4 Apr 2006, Zoltan Menyhart wrote:
> Christoph Lameter wrote:
>
> > Could you come up with a patch? Currently, I do not seem to be able to spend
> > enough time on it.
>
> Please have a look at this sample.
Could decomplicate this? Just use acquire / release and avoid the
additional intrinsics. The purpose is first of all correctness. Then we
can add some whiz bang on top. Also please sent patches inline not as
attachments.
^ permalink raw reply
* Re: [PATCH 00/15] powerpc: move some header files
From: Kumar Gala @ 2006-04-05 16:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060406020313.186a74ad.sfr@canb.auug.org.au>
On Apr 5, 2006, at 11:03 AM, Stephen Rothwell wrote:
> On Wed, 5 Apr 2006 09:28:55 -0500 Kumar Gala
> <galak@kernel.crashing.org> wrote:
>>
>> How about we do the following to remove the include hack:
>>
>> don't move the following (determine what needs them to build and
>> fixup, I dont believe any of these need to exist at this point in
>> arch/powerpc for it to build any supported arch/powerpc platform:
>
> I only moved the files that were actually required to build the
> defconfigs
> for the three 32 bit builds in arch/powerpc ...
>
>> b/include/asm-powerpc/amigappc.h | 9 ++----
>> b/include/asm-powerpc/bootinfo.h | 8 ++---
>> b/include/asm-powerpc/mpc8xx.h | 10 +++---
>> b/include/asm-powerpc/ocp.h | 7 ++--
>> b/include/asm-powerpc/ocp_ids.h | 6 ++--
>> b/include/asm-powerpc/open_pic.h | 10 +++---
>
> So maybe I could attempt to remove the dependencies instead of
> moving the
> files. You are right that it is worth it if we can just get rid of
> these
> files.
>
>> Duplicate these headers (then I'll go through and clean them up,
>> removing arch/ppc'ism):
>>
>> b/include/asm-powerpc/mpc83xx.h | 7 ++--
>> b/include/asm-powerpc/mpc85xx.h | 9 ++----
>
> I guess that would work, but Paulus is going to not like me as he
> already
> put all these patches into the powerpc tree. :-)
That's Paulus own doing for his premature pull :)
> Something to keep me entertained for another day.
I'm guessing you had to pull some of them in because of the following:
io.h:#include <asm-ppc/io.h>
mmu_context.h:#include <asm-ppc/mmu_context.h>
mmu.h:#include <asm-ppc/mmu.h>
pci-bridge.h:#include <asm-ppc/pci-bridge.h>
pgalloc.h:#include <asm-ppc/pgalloc.h>
pgtable.h:#include <asm-ppc/pgtable.h>
I think addressing these will make life easier with the other includes.
- kumar
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Bjorn Helgaas @ 2006-04-05 16:15 UTC (permalink / raw)
To: Zou Nan hai; +Cc: Luck, Tony, Andrew Morton, LKML, linux-ia64
In-Reply-To: <1144202706.3197.11.camel@linux-znh>
On Tuesday 04 April 2006 20:05, Zou Nan hai wrote:
> On Wed, 2006-04-05 at 07:38, Luck, Tony wrote:
> > On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > > - VGA on ia64 is broken - the screen comes up blank. But ia64 otherwise
> > > seems to work OK. I didn't have time to investigate.
> >
> > Broken in base 2.6.17-rc1 too :-( VGA comes up and prints a
> > few messages, and then goes wonky and dies. Comparing
> > what I _think_ I saw with the dmesg output, it appears to
> > die here:
>
> The wild VGA comes from the patch which changed ioremap.
>
> Now ioremap would not remap memory to region 6 unless that memory is
> marked as EFI_MEMORY_UC by EFI.
>
> Unfortunately on the Tiger Machine, VGA ram base was marked as
> EFI_MEMORY_WB instead of EFI_MEMORY_UC...
>
> So you can see the problem disappear if change VGA_MAP_MEM to use
> ioremap_nocache.
>
> But I am not quite sure if we can fully trust EFI on this attribute.
Huh. Intel firmware used to just not mention the VGA framebuffer
(0xa0000-0xc0000) at all in the EFI memory map. I think that was
clearly a bug. So maybe they fixed that by marking it WB (and
hopefully UC as well).
Tiger might support WB to the VGA framebuffer, but I don't think it
make much sense for us to use it that way. If we did, writes to the
framebuffer would just sit in the cache until forced out by something
else. Probably using WC would be the best, but we don't have a good
interface for that yet.
Tony, if you agree with this analysis and haven't fixed it yet, here's
a trivial patch.
[IA64] always map VGA framebuffer UC, even if it supports WB
EFI on some machines, e.g., Intel Tiger, reports that the VGA framebuffer
supports WB access. ioremap() prefers WB when possible, so it can work
when mapping main memory.
But it doesn't make sense to map a framebuffer WB, because the driver
doesn't flush explicitly, so updates won't make it to the device
immediately.
This is due to Zou Nan hai <nanhai.zou@intel.com>.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm5/include/asm-ia64/vga.h
===================================================================
--- work-mm5.orig/include/asm-ia64/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-ia64/vga.h 2006-04-05 09:57:55.000000000 -0600
@@ -17,7 +17,7 @@
extern unsigned long vga_console_iobase;
extern unsigned long vga_console_membase;
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x) ((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
^ permalink raw reply
* Re: 2.6.17-rc1-mm1
From: Bjorn Helgaas @ 2006-04-05 16:15 UTC (permalink / raw)
To: Zou Nan hai; +Cc: Luck, Tony, Andrew Morton, LKML, linux-ia64
In-Reply-To: <1144202706.3197.11.camel@linux-znh>
On Tuesday 04 April 2006 20:05, Zou Nan hai wrote:
> On Wed, 2006-04-05 at 07:38, Luck, Tony wrote:
> > On Tue, Apr 04, 2006 at 01:45:04AM -0700, Andrew Morton wrote:
> > > - VGA on ia64 is broken - the screen comes up blank. But ia64 otherwise
> > > seems to work OK. I didn't have time to investigate.
> >
> > Broken in base 2.6.17-rc1 too :-( VGA comes up and prints a
> > few messages, and then goes wonky and dies. Comparing
> > what I _think_ I saw with the dmesg output, it appears to
> > die here:
>
> The wild VGA comes from the patch which changed ioremap.
>
> Now ioremap would not remap memory to region 6 unless that memory is
> marked as EFI_MEMORY_UC by EFI.
>
> Unfortunately on the Tiger Machine, VGA ram base was marked as
> EFI_MEMORY_WB instead of EFI_MEMORY_UC...
>
> So you can see the problem disappear if change VGA_MAP_MEM to use
> ioremap_nocache.
>
> But I am not quite sure if we can fully trust EFI on this attribute.
Huh. Intel firmware used to just not mention the VGA framebuffer
(0xa0000-0xc0000) at all in the EFI memory map. I think that was
clearly a bug. So maybe they fixed that by marking it WB (and
hopefully UC as well).
Tiger might support WB to the VGA framebuffer, but I don't think it
make much sense for us to use it that way. If we did, writes to the
framebuffer would just sit in the cache until forced out by something
else. Probably using WC would be the best, but we don't have a good
interface for that yet.
Tony, if you agree with this analysis and haven't fixed it yet, here's
a trivial patch.
[IA64] always map VGA framebuffer UC, even if it supports WB
EFI on some machines, e.g., Intel Tiger, reports that the VGA framebuffer
supports WB access. ioremap() prefers WB when possible, so it can work
when mapping main memory.
But it doesn't make sense to map a framebuffer WB, because the driver
doesn't flush explicitly, so updates won't make it to the device
immediately.
This is due to Zou Nan hai <nanhai.zou@intel.com>.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm5/include/asm-ia64/vga.h
=================================--- work-mm5.orig/include/asm-ia64/vga.h 2006-01-02 20:21:10.000000000 -0700
+++ work-mm5/include/asm-ia64/vga.h 2006-04-05 09:57:55.000000000 -0600
@@ -17,7 +17,7 @@
extern unsigned long vga_console_iobase;
extern unsigned long vga_console_membase;
-#define VGA_MAP_MEM(x) ((unsigned long) ioremap(vga_console_membase + (x), 0))
+#define VGA_MAP_MEM(x) ((unsigned long) ioremap_nocache(vga_console_membase + (x), 0))
#define vga_readb(x) (*(x))
#define vga_writeb(x,y) (*(y) = (x))
^ permalink raw reply
* Re: [2.6.16 PATCH] Filessytem Events Reporter V2
From: Carlos Silva @ 2006-04-05 17:12 UTC (permalink / raw)
To: Yi Yang; +Cc: LKML, Andrew Morton, Evgeniy Polyakov, Matt Helsley
In-Reply-To: <4433C456.7010708@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
On Wed, 2006-04-05 at 21:21 +0800, Yi Yang wrote:
> <snip>
> +static void cleanup_dead_listener(listener * x)
> +{
> + pid_filter * p = NULL, * pq = NULL;
> + uid_filter * u = NULL, * uq = NULL;
> + gid_filter * g = NULL, * gq = NULL;
> +
> + if (p == NULL)
> + return;
> <snip>
I think you ment "if (x == NULL)" here. Otherwise, the condition will always be true.
btw, I'm not reviewing your code, just stumbled across this while reading it.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [PATCH] kexec on ia64
From: Khalid Aziz @ 2006-04-05 16:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, Fastboot mailing list, Linux ia64
In-Reply-To: <20060403212049.480ad388.akpm@osdl.org>
On Mon, 2006-04-03 at 21:20 -0700, Andrew Morton wrote:
> Khalid Aziz <khalid_aziz@hp.com> wrote:
> >
> > Add kexec support on ia64.
> >
>
> Neat. How well does it work?
Works well on my test machines - HP rx2600 and HP cx2600. Hopefully
others can test it on other machines.
> > +/*
> > + * Terminate any outstanding interrupts
> > + */
> > +void terminate_irqs(void)
> > +{
> > + struct irqaction * action;
> > + irq_desc_t *idesc;
> > + int i;
> > +
> > + for (i=0; i<NR_IRQS; i++) {
>
> for (i = 0; i < NR_IRQS; i++) {
>
> > + idesc = irq_descp(i);
> > + action = idesc->action;
> > + if (!action)
> > + continue;
> > + if (idesc->handler->end)
> > + idesc->handler->end(i);
> > + }
> > +}
>
> Could we have a bit more description of what this function does, and why we
> need it?
>
> Should other kexec-using architectures be using this? If not, why does
> ia64 need it?
>
> Thanks.
This funtion terminates any outstanding interrupts. I found it to be
necessary for devices that use level interrupt. If a device, using level
interrupt, asserted its interrupt as kernel goes into panic, nobody
acknowledges its interrupt. As a result, this interrupt stays asserted
as the new kernel comes up. All drivers in their initialization routine
should clear any pending interrupts, but most do not. As a result, when
driver attempts to use the interrupt, it is unable to since the
interrupt was already asserted and any new interrupts from the device
simply cause interrupt line to continue to be asserted. terminate_irqs()
tries to acknowledge any pending interrupts so the interrupts will be
usable when the new kernel comes up. This is not specific to ia64 and I
would think this problem would show up on other architectures as well. I
happened to find it on ia64 because HP rx2600 uses level interrupts for
SCSI controller.
--
Khalid
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
^ permalink raw reply
* Re: [PATCH] kexec on ia64
From: Khalid Aziz @ 2006-04-05 16:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, Fastboot mailing list, Linux ia64
In-Reply-To: <20060403212049.480ad388.akpm@osdl.org>
On Mon, 2006-04-03 at 21:20 -0700, Andrew Morton wrote:
> Khalid Aziz <khalid_aziz@hp.com> wrote:
> >
> > Add kexec support on ia64.
> >
>
> Neat. How well does it work?
Works well on my test machines - HP rx2600 and HP cx2600. Hopefully
others can test it on other machines.
> > +/*
> > + * Terminate any outstanding interrupts
> > + */
> > +void terminate_irqs(void)
> > +{
> > + struct irqaction * action;
> > + irq_desc_t *idesc;
> > + int i;
> > +
> > + for (i=0; i<NR_IRQS; i++) {
>
> for (i = 0; i < NR_IRQS; i++) {
>
> > + idesc = irq_descp(i);
> > + action = idesc->action;
> > + if (!action)
> > + continue;
> > + if (idesc->handler->end)
> > + idesc->handler->end(i);
> > + }
> > +}
>
> Could we have a bit more description of what this function does, and why we
> need it?
>
> Should other kexec-using architectures be using this? If not, why does
> ia64 need it?
>
> Thanks.
This funtion terminates any outstanding interrupts. I found it to be
necessary for devices that use level interrupt. If a device, using level
interrupt, asserted its interrupt as kernel goes into panic, nobody
acknowledges its interrupt. As a result, this interrupt stays asserted
as the new kernel comes up. All drivers in their initialization routine
should clear any pending interrupts, but most do not. As a result, when
driver attempts to use the interrupt, it is unable to since the
interrupt was already asserted and any new interrupts from the device
simply cause interrupt line to continue to be asserted. terminate_irqs()
tries to acknowledge any pending interrupts so the interrupts will be
usable when the new kernel comes up. This is not specific to ia64 and I
would think this problem would show up on other architectures as well. I
happened to find it on ia64 because HP rx2600 uses level interrupts for
SCSI controller.
--
Khalid
==================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
^ permalink raw reply
* Re: VPN module
From: Erich Schubert @ 2006-04-05 16:09 UTC (permalink / raw)
To: Joshua Brindle; +Cc: Christopher J. PeBenito, SE Linux
In-Reply-To: <4433DC6D.9020209@tresys.com>
Hi,
> > Creating openvpn will be fine, but the vpn module has to stay as is,
> > because we can't rename modules, because it causes upgrade issues. For
I think we'll hit that problem sooner or later, and in order to do some
automatic module loading we'll need much more magic anyway. Apart from
that I don't think we need to be very careful with upgrading policy
anyway, because the admin might have customized it.
So on the one hand, I'd try to change such obvious things like this as
early as possible (the module is badly named, it should be called vpnc!)
so it will effect as few people as possible, on the other hand we'll
probably need all this sooner or later anyway. So we should start
planning tools for that.
(e.g. how to extract dependency / conflict information from modules, how
to map packages to modules that should be loaded)
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
To understand recursion you first need to understand recursion. //\
Wirklich gute Freunde machen sich erst aus dem Staub, wenn man V_/_
sie braucht. --- Charles Maurice de Tayllerand
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH] kexec: typo in machine_kexec()
From: Eric W. Biederman @ 2006-04-05 15:49 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel, Horms, Randy.Dunlap, fastboot
In-Reply-To: <200604051624.35358.kernel@kolivas.org>
How does this look for making that comment readable?
Eric
diff --git a/arch/i386/kernel/machine_kexec.c b/arch/i386/kernel/machine_kexec.c
index f73d737..7a344b6 100644
--- a/arch/i386/kernel/machine_kexec.c
+++ b/arch/i386/kernel/machine_kexec.c
@@ -189,14 +189,11 @@ NORET_TYPE void machine_kexec(struct kim
memcpy((void *)reboot_code_buffer, relocate_new_kernel,
relocate_new_kernel_size);
- /* The segment registers are funny things, they are
- * automatically loaded from a table, in memory wherever you
- * set them to a specific selector, but this table is never
- * accessed again you set the segment to a different selector.
- *
- * The more common model is are caches where the behide
- * the scenes work is done, but is also dropped at arbitrary
- * times.
+ /* The segment registers are funny things, they have both a
+ * visible and an invisible part. Whenver the visible part is
+ * set to a specific selector, the invisible part is loaded
+ * with from a table in memory. At no other time is the
+ * descriptor table in memory accessed.
*
* I take advantage of this here by force loading the
* segments, before I zap the gdt with an invalid value.
^ permalink raw reply related
* [Bridge] Re: Rapid Spanning Tree support
From: Stephen Hemminger @ 2006-04-05 16:09 UTC (permalink / raw)
To: Miller Seth-G19426; +Cc: Bui Khanh-E12360C, bridge
In-Reply-To: <F021020DA23B6641A05E616D5EAD146373A3F9@de01exm60.ds.mot.com>
Added bridge mailing list to RSTP discussion.
On Wed, 5 Apr 2006 11:29:42 -0400
"Miller Seth-G19426" <seth.miller@motorola.com> wrote:
>
> That's an approach we were considering as well using
> http://sourceforge.net/projects/rstplib/. Was this what you were
> planning to start with or did you want to pull the code out of the
> kernel? We're willing to work with you getting the user space app
> working and any of the infrastructure changes as well. The plan would be
> to put all this work back into the community. We're also interested in
> adding 802.1s Multiple spanning tree.
>
>
> -----Original Message-----
> Actually, I would like to make RSTP (and all the spanning tree
> protocols)
> a user space utility. There are some infrastructure changes necessary
> to propagate sufficient information to do it.
I was going to leave existing STP in kernel for now, but not enable it.
For 2.6.17, I made sure that STP packets are received so application
can receive them (via LLC).
The next part would be adding a netlink interface to bridge module
to report and modify:
* interface added/deleted from bridge
* interface status change (carrier up/down)
* interface forwarding enable/disable
* forwarding table flush by interface.
^ permalink raw reply
* Re: register/unregister SATA drive
From: Lukasz Kosewski @ 2006-04-05 16:04 UTC (permalink / raw)
To: Dieter Stüken; +Cc: linux-ide
In-Reply-To: <4433E038.3040607@conterra.de>
Hey Dieter,
On 4/5/06, Dieter Stüken <stueken@conterra.de> wrote:
> is it possible to unregister a single SATA port and to detach the disk?
> how do I inform the kernel to rescan for a newly attached drive on that
> port?
To actually do this, I direct you to
http://lkml.org/lkml/2005/12/29/216
http://lkml.org/lkml/2005/12/29/215
This is the last submitted version of my hotswap patches for libata,
which, assuming that you have a Promise controller, will go and
register unplugged and plugged devices for you.
Now of course, caveats: those patches aren't updated for 2.6.16
because I haven't had time to do so and test them. And, of course,
they work with some Promise controllers only.
Until they're a) revised to work with new libata EH, b) accepted and
c) more hardware support is layered on them, they might not help you
much.
You can use the patches to figure out how to write a system which does
what you want though, provided you add a way to hook the sata_hot_plug
and sata_hot_unplug methods from the command line, for instance.
Hope this alleviates the problem a bit,
Luke Kosewski
^ permalink raw reply
* Re: [PATCH 00/15] powerpc: move some header files
From: Stephen Rothwell @ 2006-04-05 16:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <C40B1083-7953-4104-8FA3-5B9B4EBE1A77@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Wed, 5 Apr 2006 09:28:55 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> How about we do the following to remove the include hack:
>
> don't move the following (determine what needs them to build and
> fixup, I dont believe any of these need to exist at this point in
> arch/powerpc for it to build any supported arch/powerpc platform:
I only moved the files that were actually required to build the defconfigs
for the three 32 bit builds in arch/powerpc ...
> b/include/asm-powerpc/amigappc.h | 9 ++----
> b/include/asm-powerpc/bootinfo.h | 8 ++---
> b/include/asm-powerpc/mpc8xx.h | 10 +++---
> b/include/asm-powerpc/ocp.h | 7 ++--
> b/include/asm-powerpc/ocp_ids.h | 6 ++--
> b/include/asm-powerpc/open_pic.h | 10 +++---
So maybe I could attempt to remove the dependencies instead of moving the
files. You are right that it is worth it if we can just get rid of these
files.
> Duplicate these headers (then I'll go through and clean them up,
> removing arch/ppc'ism):
>
> b/include/asm-powerpc/mpc83xx.h | 7 ++--
> b/include/asm-powerpc/mpc85xx.h | 9 ++----
I guess that would work, but Paulus is going to not like me as he already
put all these patches into the powerpc tree. :-)
Something to keep me entertained for another day.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* unchecked uses of strdup
From: Jim Meyering @ 2006-04-05 16:02 UTC (permalink / raw)
To: git
In-Reply-To: <1144165927.30675.32.camel@dv>
There are pretty many uses of strdup in git's sources.
Here's one that can cause trouble if it ever returns NULL:
[from fsck-objects.c]
static int fsck_head_link(void)
{
unsigned char sha1[20];
const char *git_HEAD = strdup(git_path("HEAD"));
const char *git_refs_heads_master = resolve_ref(git_HEAD, sha1, 1);
The problem is that resolve_ref does an unconditional `stat'
on the parameter corresponding to the maybe-NULL git_HEAD.
One solution is to change such uses of strdup to uses of xstrdup.
^ permalink raw reply
* FAQ entry for loopback mounting
From: Ralph Siemsen @ 2006-04-05 16:00 UTC (permalink / raw)
To: linux-mtd
After struggling with loopback mounting jffs2 files for a while, here is
a suggestion to update the FAQ entry "I cannot loop mount a JFFS2 image"
found at http://www.linux-mtd.infradead.org/faq/jffs2.html
Caveat: I am not a MTD guru, what I document here was learned by trial
and error, and coaching by joern, tglx and dwmw2. I hope it is useful
and not entirely incorrect ;) Feedback welcome, and if you want a
HTML-ized version for the webpage, let me know.
Loopback mounting a JFFS2 image
Currently, it is not possible to mount a JFFS2 image via loopback (eg.
"mount -oloop -tjffs2 file.jffs2 /mnt/foo" does not work). There are
several close approximations: mtdram and block2mtd. An older method,
blkmtd, has recently been deprecated.
METHOD mtdram:
The mtdram method (CONFIG_MTD_MTDRAM in your kernel config, not to be
confused with the CONFIG_MTD_RAM option!) creates a MTD device in RAM.
You can copy your JFFS2 image there and then mount it, just like you
would do with a real MTD device in flash. The only downside is that it
eats up a lot of memory (eg. don't try making a 1GiB mtdram device).
# modprobe mtdram total_size=8192 erase_size=128
This creates a MTD device 8MiB big, with an erase size of 128kiB. Note
the implied units are kilobytes. Check in /proc/mtd to see the
newly-created device (your numbers will vary!)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00020000 "mtdram test device"
Now it can be operated like any other MTD device. To "fill" it with
your JFFS2 image, just copy that image to /dev/mtd0. Then mount the
device somewhere.
# cp file.jffs2 /dev/mtd0
# mount -tjffs2 /dev/mtdblock0 /mnt/foo
The contents are now visible under /mnt/foo.
METHOD block2mtd:
The block2mtd method (CONFIG_MTD_BLOCK2MTD in your kernel config) can be
used to transform a block device into an MTD device. Combined with the
standard loopback device (CONFIG_BLK_DEV_LOOP), this can be used to
"mount" a JFFS2 image without the RAM overhead of the mtdram method.
You must ensure that the JFFS2 image file is padded to a multiple of the
block size when using this method, otherwise your filesystem will be
truncated to the next-to-last block, and some data will be lost. Note
that the mkfs.jffs2 utility has a -p option that will add the padding.
The first step is to create a block device from the image file using the
standard loop method.
# modprobe loop (if necessary)
# losetup /dev/loop0 /path/to/file.jffs2
Now that we have a block device, it is "made into" a MTD device using
block2mtd module:
# modprobe block2mtd block2mtd=/dev/loop0,128ki
Here the "128ki" is the erase block size. Only "ki" is accepted, due to
bugs in the parsing code. The code understands "M" and "G" but will
barf on subsequent arguments. You cannot add the logical-seeming "B",
for example, "128kiB" is not accepted. If you use no letters, then the
value is interpreted in BYTES (unlike the mtdram which assumes kiB).
There are additional options that can be passed (comma-separated): "ro"
makes the device read-only, and "sync" presumably makes it synchronous.
At this point, a new MTD device is created and can be mounted like any
other MTD device.
# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00020000 "block2mtd: /dev/loop0"
# mount -tjffs2 /dev/mtdblock0 /mnt/foo
The contents are now accessible under /mnt/foo. Note there is no need
to copy the image file into the mtd device in this case!
Note: there was an "embarrassing typo" in block2mtd in kernel 2.6.12 and
earlier, which makes it unusable. It was fixed in 2.6.13 and beyond.
And the units parsing problems described above are present in 2.6.16 but
will presumably be fixed.
-R
^ permalink raw reply
* Re: [PATCH 4/4] fix tx4938 undefined reference
From: Geoff Levand @ 2006-04-05 16:09 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ralf, linux-mips
In-Reply-To: <4433CA7E.1010504@ru.mvista.com>
Sergei Shtylyov wrote:
> I'm sorry, where do you see this option? It belongs to cross-arch KGDB
> which AFAIK is not in the Linus' kernel yet. So, NAK.
Yes, sorry about that. I'll send it off to the kgdb ML.
-Geoff
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>>
>>
>> Index: linux-2.6.16.1/arch/mips/tx4938/common/Makefile
>> ===================================================================
>> --- linux-2.6.16.1.orig/arch/mips/tx4938/common/Makefile 2006-01-02 19:21:10.000000000 -0800
>> +++ linux-2.6.16.1/arch/mips/tx4938/common/Makefile 2006-03-07 11:05:05.000000000 -0800
>> @@ -7,5 +7,5 @@
>> #
>>
>> obj-y += prom.o setup.o irq.o irq_handler.o rtc_rx5c348.o
>> -obj-$(CONFIG_KGDB) += dbgio.o
>> +obj-$(CONFIG_KGDB_8250) += dbgio.o
>
> WBR, Sergei
>
^ permalink raw reply
* Re: How should I handle binary file with GIT
From: Shawn Pearce @ 2006-04-05 15:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Nicolas Pitre, Jakub Narebski, git
In-Reply-To: <86wte4rq3d.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Nicolas" == Nicolas Pitre <nico@cam.org> writes:
>
> >> IIRC bsdiff is used by Firefox to distribute binary software updates.
> >> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but
> >> supposedly offers worse compression (bigger diffs).
>
> Nicolas> We already have our own delta code for pack storage.
>
> I think the issue is related to being able to cherry-pick and merge
> when binaries are involved. I've been worried about that myself.
> How well are binaries supported these days for all the operations
> we're taking for granted? When is a "diff" expected to be a real
> "diff" and not just "binary files differ"?
The clearly safe approach is to include the full SHA1 ID of the
old object the patch was created from and use the xdelta in the
patch only as a means of transporting a compressed form of the new
version of the object. If git-diff starts to export say a base 64
encoding of the xdelta then it should also include the full SHA1
ID for binary files, even if --full-index wasn't given.
git-apply should only apply an xdelta patch to the exact same
old object. If the tree currently has a different object at that
path then reject the patch entirely.
If a path has a different object then the patch was based on then
we can do one of two things to be ``nice'' to the human:
- If the old blob exists in the repository (it just isn't the
current version at that path) then generate a temporary merge
file holding the old blob with the delta applied. The user can
then finish the merge with whatever tool understands that binary
file format, or do the merge by hand.
- Supply a ``do it anyway'' flag to git-apply. If this flag is
given on the command line then the binary file is patched even
though the object versions differ. For some binary file formats
this may actually be a valid thing to do. But it probably isn't
for a very large percentage of known file formats.
I could see some cases where it might be nice to be able to perform
specialized merge handling of binary files via hooks or filters.
For example *.tar.gz, *.zip, *.jar - these files are all just
compressed trees. They should be somewhat mergeable with the same
semantics as other trees in GIT. Of course one could just unpack
these into a directory and let GIT track the directory instead,
but this is rather inconvenient in a Java project. :-)
If I recall correctly OpenOffice document files are XML compressed
into ZIP archives. The XML *might* diff/patch cleanly as plain text.
The other resources in that archive are typically binary graphic
files and the like, which of course wouldn't diff/patch nicely.
But being able to diff/patch the main content might be semi-useful.
--
Shawn.
^ permalink raw reply
* RE: Compiling xenoprof
From: Santos, Jose Renato G @ 2006-04-05 15:54 UTC (permalink / raw)
To: David Carr, xen-devel
David,
You are right. This is not very clean.
Yes, you need to do a "make" to create the xen0 and xenU trees
before applying the patch in step c).
If you configure the kernel with oprofile support (CONFIG_OPROFILE)
before step c) you will probably get a compilation error when
you run make since the patch was not applied yet. You could either delay
setting (CONFIG_OPROFILE) for after you apply patch "c" or you
can apply the patch after you get the compilation error, and then
run make again.
It would be better if there was a "make" option to create the
xen0/xenU trees without compiling them. Does anybody know if
there is such an option? I remember looking for it in the Makefile
and not finding it, but this was a while ago.
We are now working on getting the xenoprof code included in
xen-unstable.
This should make life much easier for those wanting to use oprofile.
Renato
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
>> David Carr
>> Sent: Tuesday, April 04, 2006 7:31 PM
>> To: xen-devel@lists.xensource.com
>> Subject: [Xen-devel] Compiling xenoprof
>>
>> I'm having some trouble compiling Xen 3.0.0 with the
>> xenoprof patches.
>>
>> The xenoprof instructions say:
>>
>> In order to run OProfile in Xen environments four patches
>> are needed:
>> a) xenoprof-2.0-xen-3.0.0.patch
>> Patch for Xen hypervisor.
>> b) xenoprof-2.0-linux-2.6-sparse.patch
>> Patch for Xenolinux. Contains oprofile architecture
>> specific driver
>> for xen (Apply to linux-sparse tree in Xen source tree)
>> c) xenoprof-2.0-linux-2.6.12.patch
>> Patch for oprofile kernel module in linux 2.6.12.
>> Contain modifications
>> to generic oprofile driver code to support xen. (Apply
>> twice, once to
>> dom0 and once to domU trees)
>>
>>
>> Every thing goes fine until part c. The linux-2.6.12-xen0
>> and linux-2.6.12-xenU directories are empty until you build
>> xen (and therefore can't be patched yet.) Doing a make
>> world will populate these trees but also compiles everything.
>>
>> What is the proper sequence of patching and make commands to
>> build a xenoprof tree?
>>
>> Thanks,
>> David Carr
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
^ permalink raw reply
* bad tcp checksum
From: Jan den Ouden (ml) @ 2006-04-05 15:51 UTC (permalink / raw)
To: netfilter@lists.netfilter.org
Hi,
I'm seeing a strange problem with kernel 2.6.12 Xen domain0 with all
netfilter options compiled in. I'm trying to do port forwarding to an
internal machine from an internet gateway box.
What works ok is forwarding from gateway:143 to internalmachine:143.
But when I forward from gateway:1000 to internalmachine:143 I get bad
TCP checksums on the return packets. These packets are ignored on the
client machine on the external internet.
Iptables rules:
*nat
-A PREROUTING -d 213.84.168.6 -i ppp0 -p tcp -m tcp --dport 143 -j DNAT
--to-destination 192.168.50.3:143
-A PREROUTING -d 213.84.168.6 -i ppp0 -p tcp -m tcp --dport 1001 -j DNAT
--to-destination 192.168.50.3:143
-A POSTROUTING -s 192.168.50.0/255.255.255.0 -o ppp0 -j SNAT --to
213.84.168.6
Example trace from client machine:
root@host2:/home/jan# tcpdump -vvv -r trace
reading from file trace, link-type EN10MB (Ethernet)
12:08:37.271198 IP (tos 0x10, ttl 64, id 48778, offset 0, flags [DF],
proto: TCP (6), length: 60) host2.denouden.info.32784 > vdmheen.nl.1001:
S, cksum 0xc616 (correct), 3872473067:3872473067(0) win 5840 <mss
1460,sackOK,timestamp 229729 0,nop,wscale 0>
12:08:37.304060 IP (tos 0x40, ttl 54, id 0, offset 0, flags [DF],
proto: TCP (6), length: 60) vdmheen.nl.1001 > host2.denouden.info.32784:
S, cksum 0xff8a (correct), 2453556454:2453556454(0) ack 3872473068 win
5792 <mss 1460,sackOK,timestamp 5433137 229729,nop,wscale 2>
12:08:37.304101 IP (tos 0x10, ttl 64, id 48779, offset 0, flags [DF],
proto: TCP (6), length: 52) host2.denouden.info.32784 > vdmheen.nl.1001:
., cksum 0x2e1e (correct), 1:1(0) ack 1 win 5840 <nop,nop,timestamp
229733 5433137>
12:08:37.349163 IP (tos 0x40, ttl 54, id 43987, offset 0, flags [DF],
proto: TCP (6), length: 209) vdmheen.nl.1001 >
host2.denouden.info.32784: P, cksum 0xc246 (incorrect (-> 0xbeec),
1:158(157) ack 1 win 1448 <nop,nop,timestamp 5433141 229733>
12:08:37.574322 IP (tos 0x40, ttl 54, id 43989, offset 0, flags [DF],
proto: TCP (6), length: 209) vdmheen.nl.1001 >
host2.denouden.info.32784: P, cksum 0xc22f (incorrect (-> 0xbed5),
1:158(157) ack 1 win 1448 <nop,nop,timestamp 5433164 229733>
12:08:38.034079 IP (tos 0x40, ttl 54, id 43991, offset 0, flags [DF],
proto: TCP (6), length: 209) vdmheen.nl.1001 >
host2.denouden.info.32784: P, cksum 0xc201 (incorrect (-> 0xbea7),
1:158(157) ack 1 win 1448 <nop,nop,timestamp 5433210 229733>
12:08:38.953738 IP (tos 0x40, ttl 54, id 43993, offset 0, flags [DF],
proto: TCP (6), length: 209) vdmheen.nl.1001 >
host2.denouden.info.32784: P, cksum 0xc1a5 (incorrect (-> 0xbe4b),
1:158(157) ack 1 win 1448 <nop,nop,timestamp 5433302 229733>
12:08:40.794190 IP (tos 0x40, ttl 54, id 43995, offset 0, flags [DF],
proto: TCP (6), length: 209) vdmheen.nl.1001 >
host2.denouden.info.32784: P, cksum 0xc0ed (incorrect (-> 0xbd93),
1:158(157) ack 1 win 1448 <nop,nop,timestamp 5433486 229733>
Does anybody have any idea what's wrong here? I've tried to search on
Google for an answer, but I couldn't find any people with similar problems.
Thanks,
Jan
^ permalink raw reply
* 2.6.17-rc1 perfmon2 new code base + libpfm available
From: Stephane Eranian @ 2006-04-05 15:43 UTC (permalink / raw)
To: perfmon; +Cc: linux-ia64, linux-kernel, oprofile-list, perfctr-devel
Hello,
I have released another version of the perfmon new code base package.
This release is relative to 2.6.17-rc1
There were, once again, new system calls added. As such a new libpfm is
necessary.
This new kernel patch includes several changes:
- Merged i386 and x86_64 perfmon.c architecture specific codes
- Merged PMU description modules for em64t and p4.
- support for automatic loading of PMU description modules if
CONFIG_KMOD=y. Make sure you run make modules_install
- MIPS patches are back and are applied onto the mainline kernel
This release uses the new/mod patch breakdown for all architectures.
To apply, you can simply do:
cat ../perfmon-new-base-060405/*.diff | patch -p1
The new version of the library, libpfm, includes the following changes:
- updated to match 2.6.17-rc1 new system call numbers
- modified pfmlib.h to use 64-bit integer for generic PMC register
(submitted by Kevin Corry from IBM)
I have finally created a minimal home page for the project. So now
you can access the latest news and files from:
http://perfmon2.sf.net
I received notification from SF.net, that the libpfm package has been installed
into our CVS repository. It should become visible fairly quickly now. Once this
happens, I will update the tree to include this new version of the library.
Enjoy,
--
-Stephane
^ permalink raw reply
* Re: libata machine check on Alpha
From: Jonathan Blake Benson @ 2006-04-05 15:48 UTC (permalink / raw)
To: albertl; +Cc: linux-ide
In-Reply-To: <4431D5F5.4010905@tw.ibm.com>
On Tue, 04 Apr 2006 10:12:05 +0800, you wrote:
>Tejun Heo wrote:
>> Jonathan Blake Benson wrote:
>>
>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller. I
>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>> shot, and it no longer longer panics. I still have a Lite-ON DVD ROM
>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>> can avoid using the onboard CMD646.
>>>
>>> No panic this time, though it appears to throw a machine check. The
>>> system continues all the way to multi-user, and the Maxtor drives are
>>> usable. Hope the attached dmesg helps. Let me know if I can be of
>>> any assitance.
>>>
>>
>> Can you build your kernel with ATA_DEBUG set and post dmesg? Just
>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>> include/linux/libata.h
>>
>For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>workaround should also be turned on as well. (in linux/libata.h)
>
>My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>need it.
Albert, enabling the ATAPI_ENABLE_DMADIR workaround did the trick.
The DVD-ROM drive now works as it should. Thanks again!
Jonathan Benson
libata version 1.20 loaded.
sata_sil 0000:00:09.0: version 0.9
sata_sil 0000:00:09.0: cache line size not set. Driver may not
function
sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix
PCI: Setting latency timer of device 0000:00:09.0 to 64
ata1: SATA max UDMA/100 cmd 0xFFFFFC88093C1080 ctl 0xFFFFFC88093C108A
bmdma 0xFF
FFFC88093C1000 irq 19
ata2: SATA max UDMA/100 cmd 0xFFFFFC88093C10C0 ctl 0xFFFFFC88093C10CA
bmdma 0xFF
FFFC88093C1008 irq 19
ata3: SATA max UDMA/100 cmd 0xFFFFFC88093C1280 ctl 0xFFFFFC88093C128A
bmdma 0xFF
FFFC88093C1200 irq 19
ata4: SATA max UDMA/100 cmd 0xFFFFFC88093C12C0 ctl 0xFFFFFC88093C12CA
bmdma 0xFF
FFFC88093C1208 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c68 86:3a01
87:4003 88:007f
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01
87:4003 88:007f
ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01
87:4003 88:007f
ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata3(0): applying bridge limits
ata3: dev 0 configured for UDMA/100
scsi2 : sata_sil
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000
87:0000 88:0007
ata4: dev 0 ATAPI, max UDMA/33
ata4: dev 0 configured for UDMA/33
scsi3 : sata_sil
Vendor: ATA Model: Maxtor 6Y120P0 Rev: YAR4
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: Maxtor 6Y120P0 Rev: YAR4
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: Maxtor 6Y120P0 Rev: YAR4
Type: Direct-Access ANSI SCSI revision: 05
Vendor: LITE-ON Model: DVD SOHD-167T Rev: 9S16
Type: CD-ROM ANSI SCSI revision: 05
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1
sd 2:0:0:0: Attached scsi disk sdc
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 3:0:0:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
sr 3:0:0:0: Attached scsi generic sg3 type 5
^ permalink raw reply
* Re: Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)
From: Ewan Mellor @ 2006-04-05 15:47 UTC (permalink / raw)
To: John D. Ramsdell; +Cc: xen-devel
In-Reply-To: <ogt8xqk2fzc.fsf@divan.mitre.org>
On Wed, Apr 05, 2006 at 11:34:47AM -0400, John D. Ramsdell wrote:
> Furthermore, a use of "xm top" asks me to report a bug to this list.
Could you open a bug in Bugzilla, please, and run xen-bugtool to attach your
logs to it?
Thanks,
Ewan.
^ 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.