* Re: [PATCH] powerpc: Kill machine numbers
From: Olof Johansson @ 2006-03-24 18:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel list
In-Reply-To: <1143187298.3710.3.camel@localhost.localdomain>
On Fri, Mar 24, 2006 at 07:01:38PM +1100, Benjamin Herrenschmidt wrote:
>
> > It would be very useful to print the ppc_md.name of the found machine
> > here, even without debugging enabled.
>
> Not sure ... without debugging enabled, it's likely that you won't see
> anything that early anyway :)
True, but it'd be in the dmesg, and get printed when the console comes up.
> > It's really weird that IBM chose to use "chrp" to describe a
> > PAPR-compliant platform. I guess it's for historical reasons, but it
> > sure isn't CHRP any more.
>
> Yup, I'm trying to get that changed in the architecture but even if I'm
> successful, we'll have to deal with existing machines.
Right, it was mostly a side comment.
> > > + is _not_ "chrp" as this will be matched by the kernel to be a
> > > + CHRP machine on 32 bits kernel or a pSeries on 64 bits kernels
> >
> > ...or a PAPR-compliant machine on 64-bit kernels.
> >
> > (Also, "xx-bit kernels", not "xx bits kernels").
>
> yeah yeah :) Thanks for the review anyway !
Hey, I couldn't find much technical issues, so I ended up reading your
comments and picking errors there instead. :-)
-Olof
^ permalink raw reply
* powerpc: fix hvc-rtas comments
From: Arnd Bergmann @ 2006-03-24 18:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cbe-oss-dev, linux-kernel
In-Reply-To: <200603232336.19683.arnd@arndb.de>
As notice by Olof Johansson, the comment about module_exit
in hvc_rtas is rather confusing, so remove it.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linus-2.6/drivers/char/hvc_rtas.c
===================================================================
--- linus-2.6.orig/drivers/char/hvc_rtas.c
+++ linus-2.6/drivers/char/hvc_rtas.c
@@ -119,7 +119,7 @@ static void __exit hvc_rtas_exit(void)
if (hvc_rtas_dev)
hvc_remove(hvc_rtas_dev);
}
-module_exit(hvc_rtas_exit); /* before drivers/char/hvc_console.c */
+module_exit(hvc_rtas_exit);
/* This will happen prior to module init. There is no tty at this time? */
static int hvc_rtas_console_init(void)
^ permalink raw reply
* Re: Detecting deadlocks with hypervisor..
From: T S @ 2006-03-24 18:57 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <20060319131735.GA13272@leeni.uk.xensource.com>
>From: Ewan Mellor
>To: Thileepan Subramaniam CC: xen-devel@lists.xensource.com
>Subject: Re: [Xen-devel] Detecting deadlocks with hypervisor..
>Date: Sun, 19 Mar 2006 13:17:35 +0000
>
>On Sat, Mar 18, 2006 at 06:14:09PM -0800, Thileepan Subramaniam wrote:
>
> > Hello,
> >
> > I am trying to see if the hypervisor can be used to detect deadlocks in
>the
> > guest VMs. My goal is to detect if a guest OS is deadlocked, and if it
>is,
> > then create a clone of the deadlocked OS without the locking condition,
>and
> > letting the clone run. While the clone runs I am hoping to generate some
> > hints that could tell me what caused the deadlock.
> >
> > I simulated a deadlock/hang situation in a guest OS (by loading a badly
> > written module to the kernel) and when the guestOS kernel was hanging, I
> > ran "xm save" from Dom-0. But this command waits forever.
> >
> > I tried to follow the flow of the .py files (XendCheckpoint.py etc.).
>These
> > seem to be called when I run 'xm save'. But beyond a point I am not sure
> > what the python scripts do. I also see some libxc files such as
> > xc_linux_save.c, but I am not sure who is using it (Dom-0 or Xen or the
> > XenU). Can someone help me by explaining me what happens behind the
>scene
> > when "xm save" is called ? Is there any good documentation explaining
>which
> > actions are done by which layers (eg: python layer, C layer etc).
>
>xc_save, the executable, calls xc_linux_save, the libxc function.
>Depending
>upon whether this is a live or non-live save, some stuff is done (see
>xc_linux_save for details). The Python layer is then called back,
>requesting
>that the domain is suspended. This request is passed through to the guest
>by
>writing /local/domain/<domid>/control/shutdown = suspend in the store.
>This
>is seen by the guest (a watch fires inside reboot.c) and then the guest
>suspends itself. This is probably where you are falling down -- if the
>guest
>kernel is completely deadlocked, it's going to struggle to suspend itself
>correctly.
>
>If a suspend completes correctly, Xend will see it (another watch will
>fire),
>and xc_linux_save will be free to complete the save.
So, I went and experimented this: basically, I changed XendCheckpoint.py to
NOT wait for the guest to shutdown; I also changed xc_linux_save() to
proceed saving without waiting (essentially, suspend_and_state() returns 0
instead of retrying repeateedly). With this I am able to save a deadlocked
kernel smoothly.
But when I try restore, I get this error message:
Error: /usr/lib/xen/bin/xc_restore 10 19 5 34816 1 2 failed
And the log says,
[2006-03-24 13:48:42 xend] DEBUG (XendCheckpoint:152) [xc_restore]:
/usr/lib/xen/bin/xc_restore 10 19 5 34816 1 2
[2006-03-24 13:48:42 xend] ERROR (XendCheckpoint:231) xc_linux_restore
start: max_pfn = 8800
[2006-03-24 13:48:42 xend] ERROR (XendCheckpoint:231) Increased domain
reservationby22000KB
[2006-03-24 13:48:42 xend] ERROR (XendCheckpoint:231) Reloading memory
pages: 0%
[2006-03-24 13:48:54 xend] ERROR (XendCheckpoint:231) Received all pages (0
races)
[2006-03-24 13:48:54 xend] ERROR (XendCheckpoint:231) Failed to pin batch of
22 page tables: 22
[2006-03-24 13:48:54 xend] ERROR (XendCheckpoint:231) Restore exit with rc=1
Any clue .. so that i can overcome this and restore the kernel to its
previous state (i.e., deadlocked state) ?
thanks,
TS
> > Also, does it seem viable to clone a copy of a deadlocked guest OS in
>the
> > first place?
>
>If you have a byte-for-byte copy of a deadlocked guest, even if you could
>suspend it, surely it will be deadlocked when it is resumed. How do you
>intend to break the deadlock, and how is it easier to do that from outside
>than it is to perform deadlock detection in the guest?
>
>Ewan.
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
^ permalink raw reply
* Re: [PATCH 0 of 18] ipath driver - for inclusion in 2.6.17
From: Roland Dreier @ 2006-03-24 18:57 UTC (permalink / raw)
To: Bryan O'Sullivan; +Cc: akpm, greg, linux-kernel, openib-general
In-Reply-To: <patchbomb.1143175292@eng-12.pathscale.com>
Bryan> Hi - This is a submission of the ipath driver for inclusion
Bryan> in 2.6.17. Andrew, if this looks good to you, please
Bryan> apply.
It's customary to work through subsystem maintainers to merge new drivers...
Bryan> We have addressed all earlier rounds of feedback; the
Bryan> driver is stable; it compiles with no compiler or sparse
Bryan> warnings against current -git (it's comprehensively
Bryan> annotated for sparse); and I think it's in good shape. We
Bryan> have gone to great lengths over the past several months to
Bryan> make it an exemplary kernel citizen.
I merged this series into my git tree at
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git ipath
I fixed a couple of minor whitespace problems and made it actually
build (hint: the constant RDMA_NODE_IB_CA does not exist in the
upstream kernel).
It seems you need to fix up your Kconfig dependencies somewhat. On
x86_64 allnoconfig + CONFIG_PCI=y, CONFIG_PCI_MSI=y,
CONFIG_INFINIBAND=y, CONFIG_IPATH_CORE=y, CONFIG_INFINIBAND_IPATH=y, I get:
drivers/built-in.o: In function `ipath_free_pddata': undefined reference to `kfree_skb'
drivers/built-in.o: In function `ipath_alloc_skb': undefined reference to `__alloc_skb'
drivers/built-in.o: In function `ipath_kreceive': undefined reference to `skb_over_panic'
drivers/built-in.o: In function `ipath_init_chip': undefined reference to `kfree_skb'
It also looks like there are a few problems on ia64:
drivers/infiniband/hw/ipath/ipath_verbs.c:733: warning: implicit declaration of function `atomic_set_mask'
drivers/infiniband/hw/ipath/ipath_verbs.c:734: warning: implicit declaration of function `atomic_clear_mask'
drivers/infiniband/hw/ipath/ipath_verbs.c: In function `show_stats':
drivers/infiniband/hw/ipath/ipath_verbs.c:1184: warning: long long unsigned int format, u64 arg (arg 4)
drivers/infiniband/hw/ipath/ipath_verbs.c:1184: warning: long long unsigned int format, u64 arg (arg 5)
drivers/infiniband/hw/ipath/ipath_pe800.c: In function `ipath_pe_handle_hwerrors':
drivers/infiniband/hw/ipath/ipath_pe800.c:353: warning: long long unsigned int format, long unsigned int arg (arg 5)
drivers/infiniband/hw/ipath/ipath_pe800.c:353: warning: long long unsigned int format, long unsigned int arg (arg 3)
and then the build fails with:
drivers/built-in.o(.text+0x133aa2): In function `ipath_modify_port':
: undefined reference to `atomic_set_mask'
drivers/built-in.o(.text+0x133ac2): In function `ipath_modify_port':
: undefined reference to `atomic_clear_mask'
I also wouldn't say the driver is sparse clean. I get 270 lines of
warnings when I try it:
drivers/infiniband/hw/ipath/ipath_mad.c:103:17: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:103:17: expected restricted unsigned long long [usertype] node_guid
drivers/infiniband/hw/ipath/ipath_mad.c:103:17: got unsigned long long
drivers/infiniband/hw/ipath/ipath_mad.c:289:9: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:289:9: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/infiniband/hw/ipath/ipath_mad.c:289:9: got restricted unsigned short [usertype] [force] <noident>
drivers/infiniband/hw/ipath/ipath_mad.c:537:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_mad.c:537:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_mad.c:537:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_mad.c:902:27: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:902:27: expected restricted unsigned short [usertype] symbol_error_counter
drivers/infiniband/hw/ipath/ipath_mad.c:902:27: got int
drivers/infiniband/hw/ipath/ipath_mad.c:916:22: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:916:22: expected restricted unsigned short [usertype] port_rcv_errors
drivers/infiniband/hw/ipath/ipath_mad.c:916:22: got int
drivers/infiniband/hw/ipath/ipath_mad.c:921:30: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:921:30: expected restricted unsigned short [usertype] port_rcv_remphys_errors
drivers/infiniband/hw/ipath/ipath_mad.c:921:30: got int
drivers/infiniband/hw/ipath/ipath_mad.c:926:25: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:926:25: expected restricted unsigned short [usertype] port_xmit_discards
drivers/infiniband/hw/ipath/ipath_mad.c:926:25: got int
drivers/infiniband/hw/ipath/ipath_mad.c:931:21: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:931:21: expected restricted unsigned int [usertype] port_xmit_data
drivers/infiniband/hw/ipath/ipath_mad.c:931:21: got unsigned int
drivers/infiniband/hw/ipath/ipath_mad.c:935:20: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:935:20: expected restricted unsigned int [usertype] port_rcv_data
drivers/infiniband/hw/ipath/ipath_mad.c:935:20: got unsigned int
drivers/infiniband/hw/ipath/ipath_mad.c:939:24: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:939:24: expected restricted unsigned int [usertype] port_xmit_packets
drivers/infiniband/hw/ipath/ipath_mad.c:939:24: got unsigned int
drivers/infiniband/hw/ipath/ipath_mad.c:944:23: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_mad.c:944:23: expected restricted unsigned int [usertype] port_rcv_packets
drivers/infiniband/hw/ipath/ipath_mad.c:944:23: got unsigned int
drivers/infiniband/hw/ipath/ipath_qp.c:581:9: warning: incorrect type in return expression (different base types)
drivers/infiniband/hw/ipath/ipath_qp.c:581:9: expected unsigned int
drivers/infiniband/hw/ipath/ipath_qp.c:581:9: got restricted unsigned int [usertype] [force] <noident>
drivers/infiniband/hw/ipath/ipath_rc.c:103:16: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:103:16: expected restricted unsigned int [usertype] aeth
drivers/infiniband/hw/ipath/ipath_rc.c:103:16: got unsigned int
drivers/infiniband/hw/ipath/ipath_rc.c:116:17: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:116:17: expected restricted unsigned int [usertype] aeth
drivers/infiniband/hw/ipath/ipath_rc.c:116:17: got unsigned int
drivers/infiniband/hw/ipath/ipath_rc.c:147:19: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:147:19: expected restricted unsigned int [usertype] aeth
drivers/infiniband/hw/ipath/ipath_rc.c:147:19: got unsigned int
drivers/infiniband/hw/ipath/ipath_rc.c:158:16: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:158:16: expected restricted unsigned int [usertype] aeth
drivers/infiniband/hw/ipath/ipath_rc.c:158:16: got unsigned int
drivers/infiniband/hw/ipath/ipath_rc.c:519:45: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:519:45: expected restricted unsigned long long [usertype] interface_id
drivers/infiniband/hw/ipath/ipath_rc.c:519:45: got unsigned long long
drivers/infiniband/hw/ipath/ipath_rc.c:519:45: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:519:45: expected restricted unsigned long long [usertype] interface_id
drivers/infiniband/hw/ipath/ipath_rc.c:519:45: got unsigned long long
drivers/infiniband/hw/ipath/ipath_rc.c:656:15: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:656:15: expected restricted unsigned int [usertype] aeth
drivers/infiniband/hw/ipath/ipath_rc.c:656:15: got unsigned int
drivers/infiniband/hw/ipath/ipath_rc.c:1456:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1456:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1456:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1147:12: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1147:12: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1147:12: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1163:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1163:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1163:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1253:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1253:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1253:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_rc.c:1609:16: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:1609:16: expected restricted unsigned int [assigned] [usertype] imm_data
drivers/infiniband/hw/ipath/ipath_rc.c:1609:16: got unsigned int [unsigned] [usertype] <noident>
drivers/infiniband/hw/ipath/ipath_rc.c:1650:24: warning: incorrect type in argument 3 (different base types)
drivers/infiniband/hw/ipath/ipath_rc.c:1650:24: expected int [signed] sig
drivers/infiniband/hw/ipath/ipath_rc.c:1650:24: got restricted unsigned int
drivers/infiniband/hw/ipath/ipath_uc.c:288:46: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_uc.c:288:46: expected restricted unsigned long long [usertype] interface_id
drivers/infiniband/hw/ipath/ipath_uc.c:288:46: got unsigned long long
drivers/infiniband/hw/ipath/ipath_uc.c:362:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_uc.c:362:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_uc.c:362:10: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_uc.c:473:16: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_uc.c:473:16: expected restricted unsigned int [assigned] [usertype] imm_data
drivers/infiniband/hw/ipath/ipath_uc.c:473:16: got unsigned int [unsigned] [usertype] <noident>
drivers/infiniband/hw/ipath/ipath_uc.c:517:24: warning: incorrect type in argument 3 (different base types)
drivers/infiniband/hw/ipath/ipath_uc.c:517:24: expected int [signed] sig
drivers/infiniband/hw/ipath/ipath_uc.c:517:24: got restricted unsigned int
drivers/infiniband/hw/ipath/ipath_uc.c:602:16: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_uc.c:602:16: expected restricted unsigned int [addressable] [assigned] [usertype] imm_data
drivers/infiniband/hw/ipath/ipath_uc.c:602:16: got unsigned int [unsigned] [usertype] <noident>
drivers/infiniband/hw/ipath/ipath_ud.c:321:46: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_ud.c:321:46: expected restricted unsigned long long [usertype] interface_id
drivers/infiniband/hw/ipath/ipath_ud.c:321:46: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ud.c:456:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_ud.c:456:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_ud.c:456:11: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_ud.c:457:13: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_ud.c:457:13: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_ud.c:457:13: warning: cast to restricted type
drivers/infiniband/hw/ipath/ipath_ud.c:526:16: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_ud.c:526:16: expected restricted unsigned int [assigned] [usertype] imm_data
drivers/infiniband/hw/ipath/ipath_ud.c:526:16: got unsigned int [unsigned] [usertype] <noident>
drivers/infiniband/hw/ipath/ipath_ud.c:617:23: warning: incorrect type in argument 3 (different base types)
drivers/infiniband/hw/ipath/ipath_ud.c:617:23: expected int [signed] sig
drivers/infiniband/hw/ipath/ipath_ud.c:617:23: got restricted unsigned int
drivers/infiniband/hw/ipath/ipath_verbs.c:654:19: error: incompatible types in conditional expression (different base types)
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: warning: incorrect type in argument 4 (different base types)
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: expected int
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: got restricted unsigned short <noident>
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: warning: incorrect type in argument 5 (different base types)
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: expected int
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: got restricted unsigned short <noident>
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: warning: incorrect type in argument 6 (different base types)
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: expected int
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: got restricted unsigned short <noident>
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: warning: incorrect type in argument 7 (different base types)
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: expected int
drivers/infiniband/hw/ipath/ipath_copy.c:104:2: got restricted unsigned short <noident>
drivers/infiniband/hw/ipath/ipath_copy.c:432:14: error: incompatible types for operation (!=)
drivers/infiniband/hw/ipath/ipath_driver.c:669:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:671:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:673:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:675:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:677:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:679:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:681:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:683:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:685:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:687:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:689:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:691:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:693:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:695:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:697:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:699:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:701:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:703:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:705:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:707:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:709:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:711:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:713:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:715:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:717:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:719:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:721:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:723:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:725:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:727:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:729:10: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_driver.c:1075:4: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:290:5: warning: incorrect type in initializer (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:290:5: expected restricted unsigned long long static const [toplevel] [usertype] infinipath_hwe_htcmemparityerr_mask
drivers/infiniband/hw/ipath/ipath_ht400.c:290:5: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ht400.c:295:5: warning: incorrect type in initializer (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:295:5: expected restricted unsigned long long static const [toplevel] [usertype] infinipath_hwe_htclnkabyte0crcerr
drivers/infiniband/hw/ipath/ipath_ht400.c:295:5: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ht400.c:297:5: warning: incorrect type in initializer (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:297:5: expected restricted unsigned long long static const [toplevel] [usertype] infinipath_hwe_htclnkabyte1crcerr
drivers/infiniband/hw/ipath/ipath_ht400.c:297:5: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ht400.c:299:5: warning: incorrect type in initializer (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:299:5: expected restricted unsigned long long static const [toplevel] [usertype] infinipath_hwe_htclnkbbyte0crcerr
drivers/infiniband/hw/ipath/ipath_ht400.c:299:5: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ht400.c:301:5: warning: incorrect type in initializer (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:301:5: expected restricted unsigned long long static const [toplevel] [usertype] infinipath_hwe_htclnkbbyte1crcerr
drivers/infiniband/hw/ipath/ipath_ht400.c:301:5: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ht400.c:346:17: warning: cast from restricted type
drivers/infiniband/hw/ipath/ipath_ht400.c:382:8: warning: incorrect type in argument 3 (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:382:8: expected unsigned long long [unsigned] [usertype] value
drivers/infiniband/hw/ipath/ipath_ht400.c:382:8: got restricted unsigned long long [usertype] ipath_hwerrmask
drivers/infiniband/hw/ipath/ipath_ht400.c:385:3: warning: cast from restricted type
drivers/infiniband/hw/ipath/ipath_ht400.c:411:9: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_ht400.c:411:9: expected restricted unsigned long long [usertype] hwerrs
drivers/infiniband/hw/ipath/ipath_ht400.c:411:9: got unsigned long long
drivers/infiniband/hw/ipath/ipath_ht400.c:421:20: error: incompatible types for operation (==)
drivers/infiniband/hw/ipath/ipath_ht400.c:434:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:448:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:449:3: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:449:3: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_ht400.c:449:3: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:449:3: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_ht400.c:492:9: error: incompatible types for operation (<<)
drivers/infiniband/hw/ipath/ipath_ht400.c:493:25: error: incompatible types for operation (>>)
drivers/infiniband/hw/ipath/ipath_ht400.c:493:11: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_ht400.c:500:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:502:25: error: incompatible types for operation (>>)
drivers/infiniband/hw/ipath/ipath_ht400.c:502:11: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_ht400.c:509:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:511:25: error: incompatible types for operation (>>)
drivers/infiniband/hw/ipath/ipath_ht400.c:511:11: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_ht400.c:518:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:520:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:522:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:524:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:526:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:532:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:534:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:536:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:538:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:553:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:556:34: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:556:6: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_ht400.c:559:35: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:564:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:574:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_ht400.c:576:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_init_chip.c:415:24: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_init_chip.c:415:24: expected restricted unsigned long long volatile [usertype] *ipath_hdrqtailptr
drivers/infiniband/hw/ipath/ipath_init_chip.c:415:24: got unsigned long long [usertype] *extern [addressable] [toplevel] ipath_port0_rcvhdrtail
drivers/infiniband/hw/ipath/ipath_init_chip.c:822:7: warning: incorrect type in argument 3 (different base types)
drivers/infiniband/hw/ipath/ipath_init_chip.c:822:7: expected unsigned long long [unsigned] [usertype] value
drivers/infiniband/hw/ipath/ipath_init_chip.c:822:7: got restricted unsigned long long [usertype] ipath_hwerrmask
drivers/infiniband/hw/ipath/ipath_init_chip.c:829:5: warning: incorrect type in argument 3 (different base types)
drivers/infiniband/hw/ipath/ipath_init_chip.c:829:5: expected unsigned long long [unsigned] [usertype] value
drivers/infiniband/hw/ipath/ipath_init_chip.c:829:5: got restricted unsigned long long [usertype] ipath_maskederrs
drivers/infiniband/hw/ipath/ipath_intr.c:103:12: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:297:26: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:298:57: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:300:27: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:370:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:375:24: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:376:3: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:376:3: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_intr.c:376:3: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:376:3: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_intr.c:380:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:397:55: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:432:31: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:444:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:452:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:456:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:459:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:471:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:503:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:521:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:539:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:542:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_intr.c:770:18: error: incompatible types for operation (==)
drivers/infiniband/hw/ipath/ipath_layer.c:1083:14: error: incompatible types for operation (!=)
drivers/infiniband/hw/ipath/ipath_pe800.c:316:9: warning: incorrect type in assignment (different base types)
drivers/infiniband/hw/ipath/ipath_pe800.c:316:9: expected restricted unsigned long long [usertype] hwerrs
drivers/infiniband/hw/ipath/ipath_pe800.c:316:9: got unsigned long long
drivers/infiniband/hw/ipath/ipath_pe800.c:325:20: error: incompatible types for operation (==)
drivers/infiniband/hw/ipath/ipath_pe800.c:338:11: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:352:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:389:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:398:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:400:25: error: incompatible types for operation (>>)
drivers/infiniband/hw/ipath/ipath_pe800.c:400:11: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_pe800.c:407:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:409:25: error: incompatible types for operation (>>)
drivers/infiniband/hw/ipath/ipath_pe800.c:409:11: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_pe800.c:416:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:418:25: error: incompatible types for operation (>>)
drivers/infiniband/hw/ipath/ipath_pe800.c:418:11: error: cast from unknown type
drivers/infiniband/hw/ipath/ipath_pe800.c:425:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:427:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:433:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:439:35: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:444:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:454:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:456:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:466:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:468:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:470:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:472:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:474:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:477:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_pe800.c:479:13: error: incompatible types for operation (&)
drivers/infiniband/hw/ipath/ipath_stats.c:243:55: error: incompatible types for operation (&)
^ permalink raw reply
* Re: missing git features
From: Andreas Ericsson @ 2006-03-24 18:55 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <871wwrztaz.wl%cworth@cworth.org>
Carl Worth wrote:
> On Fri, 24 Mar 2006 13:59:02 +0100, Andreas Ericsson wrote:
>
>>See how Junio does with next and pu and recommend your users to do the
>>same. There's no way of pulling a rebased branch, because the rebasing
>>destroys ancestry information, meaning the original commits other people
>>have cease to exist in your repository.
>
>
> But the "other people" still have those commits, so it should be
> rather straightforward for a tool to also perform a rebase for them
> when doing this kind of "rebased pull".
Yes they do, but you don't, so their tip won't match yours, meaning
their git will try a merge, which will fail since lots of commits are
already applied. Perhaps it would be possible to try the blobs against
each other, if anyone's interested.
> I think there's just a single
> arc of data missing showing where a rebased commit object came from.
>
> So this sounds solvable, and it is something I would very much enjoy
> having, (call me funny, but I prefer to rebase and avoid a merge
> commit when looking at independent lines of development for which
> logically there shouldn't be any "merge" required).
>
For the cases where no merge is required you could rebase several
branches on top of one and simply publish that one. If that's the case,
git would need the ability to know what branches are exported and which
arne't, which should be a lot simpler than implementing a rebased-merge
strategy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] Virtualization steps
From: Nick Piggin @ 2006-03-24 17:33 UTC (permalink / raw)
To: Kirill Korotaev
Cc: Eric W. Biederman, haveblue, linux-kernel, herbert, devel, serue,
akpm, sam, Alexey Kuznetsov, Pavel Emelianov, Stanislav Protassov
In-Reply-To: <44242A3F.1010307@sw.ru>
Kirill Korotaev wrote:
> Eric, Herbert,
>
> I think it is quite clear, that without some agreement on all these
> virtualization issues, we won't be able to commit anything good to
> mainstream. My idea is to gather our efforts to get consensus on most
> clean parts of code first and commit them one by one.
>
> The proposal is quite simple. We have 4 parties in this conversation
> (maybe more?): IBM guys, OpenVZ, VServer and Eric Biederman. We discuss
> the areas which should be considered step by step. Send patches for each
> area, discuss, come to some agreement and all 4 parties Sign-Off the
> patch. After that it goes to Andrew/Linus. Worth trying?
Oh, after you come to an agreement and start posting patches, can you
also outline why we want this in the kernel (what it does that low
level virtualization doesn't, etc, etc), and how and why you've agreed
to implement it. Basically, some background and a summary of your
discussions for those who can't follow everything. Or is that a faq
item?
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* [PATCH] powerpc: fix cell platform detection
From: Arnd Bergmann @ 2006-03-24 18:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Linux Kernel list, cbe-oss-dev
In-Reply-To: <200603240946.51793.arnd@arndb.de>
All future firmware should have 'CBEA' in the compatible
property in order to tell us that we are running on the
cell platform, so check for that as well as the now
deprecated value we have been using so far.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
This applies on top of the 'Kill machine numbers' patch
from Ben Herrenschmidt.
Index: linus-2.6/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/setup.c
+++ linus-2.6/arch/powerpc/platforms/cell/setup.c
@@ -198,7 +198,14 @@ static void __init cell_init_early(void)
static int __init cell_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, "IBM,CPB"))
+
+ /*
+ * CPBW was used on early prototypes and will be removed.
+ * The correct identification is CBEA.
+ */
+ if (!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0") &&
+ !of_flat_dt_is_compatible(root, "IBM,CBEA") &&
+ !of_flat_dt_is_compatible(root, "CBEA"))
return 0;
return 1;
^ permalink raw reply
* Re: [Ext2-devel] [RFC] [PATCH] Reducing average ext2 fsck time through fs-wide dirty bit]
From: Theodore Ts'o @ 2006-03-24 18:52 UTC (permalink / raw)
To: Valerie Henson
Cc: Andrew Morton, pbadari, linux-kernel, Ext2-devel, arjan,
zach.brown
In-Reply-To: <20060324143239.GB14508@goober>
On Fri, Mar 24, 2006 at 06:32:39AM -0800, Valerie Henson wrote:
> Note that ext3's habit of clearing indirect blocks on truncate would
> break some things I want to do in the future. (Insert secret plans
> here.)
This is fixable, but it would require making the truncate code (even
more) complicated.....
- Ted
^ permalink raw reply
* Re: State of userland headers
From: Kyle Moffett @ 2006-03-24 18:51 UTC (permalink / raw)
To: Mariusz Mazur
Cc: llh-announce, LKML Kernel, dank, nkukard, vmiklos, rseretny, lkml,
Rob Landley, jbailey, llh-discuss
In-Reply-To: <200603231811.26546.mmazur@kernel.pl>
On Mar 23, 2006, at 12:11:26, Mariusz Mazur wrote:
> There was a thread on lkml on this topic about a year ago. IIRC
> I've suggested, that the best option would be to get a new set of
> dirs somewhere inside the kernel, and gradually export the userland
> usable stuff from the kernel headers, so to (a) achieve full
> separation and (b) avoid duplication of definitions (meaning that
> kernel headers would simply include the userland ones where
> required). Linus said, that it would break stuff and so is
> unacceptable.
I seem to remember Linus saying that "breaking things is
unacceptable", not that the project was guaranteed to break things
(we would just need to be much more careful about it than most kernel
patches). What that seems to indicate to me is that an in-kernel
version would need to do the following for userspace-accessible
header files for a large number of kernel releases:
#ifndef _LINUX_HEADER_H
#define _LINUX_HEADER_H
#include <kabi/header.h>
/* Define or typedef a bunch of __kabi_ prefixes to the old
prefixes they used to have in the kernel header */
#ifndef __KERNEL__
# warning "The header file <linux/header.h> is deprecated for"
# warning "userspace, please use <kabi/header.h> instead."
#else
/* Kernel-only declarations/definitions */
#endif
If this were done carefully, all programs that compile against kernel
headers could be _fixed_ in the short term (they'd go from throwing
errors to giving a couple deprecation warnings). In the long term,
the extra ifdeffery could be removed and the <linux/*.h> headers for
which a <kabi/*.h> replacement had existed for a couple versions
could be removed. New ABIs (including IOCTLs, new syscalls, etc)
could be required to use <kabi/*.h> in the first place.
> Unfortunately I must agree with him -- I don't think it is possible
> to completely avoid duplication of definitions and all tries would
> lead to breakage of some obscure configurations -- kernel headers
> sometimes require various magic that should be avoided inside the
> userland headers at all cost. This means that initially the llh-ng
> project would need to start as a completely separate entity that
> would not require the original kernel headers for anything, and
> only later, after achieving some level of maturity and getting
> merged into the kernel, would come the time for removing some
> duplication.
I think that requiring any kind of duplication of effort on that
large a scale is virtually guaranteed not to work. It will break
down and be really painful for a long time.
> And here's where the first problem arises -- llh were so great
> initially, because they removed a lot of conflicts with glibc, by
> simply removing 'offending' linux headers and including the glibc
> counterparts (eg. linux/socket.h would do nothing else, than
> include sys/socket.h). Glibc's known for having lots of stuff
> simply 'hardcoded' into it's own set of headers, and more often
> than not, people do need to include headers from both places.
1: Ewww, bad glibc!
2: The symbols in kabi/*.h should probably all start with __kabi_
The kernel _internally_ would "#include <kabi/foo.h>" and then
promptly redefine or typedef all of those objects. If the kernel or
GLIBC want a struct renamed, they should #define
__kabi_name_of_struct name_of_struct just before including the header
file. We should also kind of frown upon non-libc userspace including
many <kabi/*.h> files, since if they get included before libc can
redefine the names to what it wants.
> I don't know about uclibc, but klibc afaik expects a lot more of
> the linux headers to be present, than glibc does.
Perhaps we should use klibc as our test-case for functional headers,
then, instead of glibc.
> Hell, if llh-ng is supposed to be a full set of apis, we can't
> expect any of the headers to come from other places, so if any
> other app (libcs included) has duplicates, that's too bad for the
> app, since it's in need of some patching.
The solution to that is to make sure that the new exported kernel
ABIs always have the __kabi_ prefix, so that we don't smash the
namespace of various programs.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [Ext2-devel] [RFC] [PATCH] Reducing average ext2 fsck time through fs-wide dirty bit]
From: Andrew Morton @ 2006-03-24 18:48 UTC (permalink / raw)
To: Valerie Henson
Cc: pbadari, linux-kernel, Ext2-devel, arjan, tytso, zach.brown
In-Reply-To: <20060324143239.GB14508@goober>
Valerie Henson <val_henson@linux.intel.com> wrote:
>
> On Wed, Mar 22, 2006 at 05:55:03PM -0800, Andrew Morton wrote:
> > Valerie Henson <val_henson@linux.intel.com> wrote:
> > >
> > > ext2 is simpler and faster than ext3 in many cases. This is sort of
> > > cheating; ext2 is simpler and faster because it makes no effort to
> > > maintain on-disk consistency and can skip annoying things like, oh,
> > > reserving space in the journal. I am looking for ways to make ext2
> > > cheat even more.
> > >
> >
> > But it might be feasible to knock up an ext3-- in which all the journal
> > operations are stubbed out.
>
> Hmm... Could we get the mark_buffer_dirty/mark_inode_dirty logic
> right?
All things are possible ;) One might add a new
ext3_minus_minus_mark_buffer_dirty(), for example, put that in all the
right places.
> Probably create a list in the stubbed journal functions and
> then mark them dirty in the journal close? However, half the reason
> I'm working on ext2 is the simplicity of the code - stubbing it out
> would solve the performance problem but not the complexity problem.
Well ext3-- won't do anything to simplify the ext3 codebase. It was just a
thought..
> Note that ext3's habit of clearing indirect blocks on truncate would
> break some things I want to do in the future. (Insert secret plans
> here.)
Ah. I guess one would need to port the ext2 truncate code.
^ permalink raw reply
* [PATCH] spufs: Fix endless protection fault on LS writes by SPE.
From: Arnd Bergmann @ 2006-03-24 18:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann, Paul Mackerras, cbe-oss-dev, linux-kernel
In-Reply-To: <20060323203423.620978000@dyn-9-152-242-103.boeblingen.de.ibm.com>
If an SPE attempts a DMA put to a local store after already doing
a get, the kernel must update the HW PTE to allow the write access.
This case was not being handled correctly.
From: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
diff -ur linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c
--- linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 12:30:07.000000000 -0600
+++ linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 10:21:26.000000000 -0600
@@ -486,14 +486,13 @@
ea = spu->dar;
dsisr = spu->dsisr;
- if (dsisr & MFC_DSISR_PTE_NOT_FOUND) {
+ if (dsisr & (MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED)) {
access = (_PAGE_PRESENT | _PAGE_USER);
access |= (dsisr & MFC_DSISR_ACCESS_PUT) ? _PAGE_RW : 0UL;
if (hash_page(ea, access, 0x300) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
}
- if ((error & CLASS1_ENABLE_STORAGE_FAULT_INTR) ||
- (dsisr & MFC_DSISR_ACCESS_DENIED)) {
+ if (error & CLASS1_ENABLE_STORAGE_FAULT_INTR) {
if ((ret = spu_handle_mm_fault(spu)) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
else
^ permalink raw reply
* [PATCH] spufs: Fix endless protection fault on LS writes by SPE.
From: Arnd Bergmann @ 2006-03-24 18:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Arnd Bergmann, cbe-oss-dev, linux-kernel
In-Reply-To: <20060323203423.620978000@dyn-9-152-242-103.boeblingen.de.ibm.com>
If an SPE attempts a DMA put to a local store after already doing
a get, the kernel must update the HW PTE to allow the write access.
This case was not being handled correctly.
From: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Mike Kistler <mkistler@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
diff -ur linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c
--- linux-2.6.15/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 12:30:07.000000000 -0600
+++ linux-2.6.15.fixed/arch/powerpc/platforms/cell/spu_base.c 2006-03-22 10:21:26.000000000 -0600
@@ -486,14 +486,13 @@
ea = spu->dar;
dsisr = spu->dsisr;
- if (dsisr & MFC_DSISR_PTE_NOT_FOUND) {
+ if (dsisr & (MFC_DSISR_PTE_NOT_FOUND | MFC_DSISR_ACCESS_DENIED)) {
access = (_PAGE_PRESENT | _PAGE_USER);
access |= (dsisr & MFC_DSISR_ACCESS_PUT) ? _PAGE_RW : 0UL;
if (hash_page(ea, access, 0x300) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
}
- if ((error & CLASS1_ENABLE_STORAGE_FAULT_INTR) ||
- (dsisr & MFC_DSISR_ACCESS_DENIED)) {
+ if (error & CLASS1_ENABLE_STORAGE_FAULT_INTR) {
if ((ret = spu_handle_mm_fault(spu)) != 0)
error |= CLASS1_ENABLE_STORAGE_FAULT_INTR;
else
^ permalink raw reply
* [PATCH] powerpc: use guarded ioremap for on-chip mappings
From: Arnd Bergmann @ 2006-03-24 18:47 UTC (permalink / raw)
To: linuxppc-dev
Cc: Benjamin Herrenschmidt, Arnd Bergmann, stk, linux-kernel,
Milton Miller, Paul Mackerras, hpenner, cbe-oss-dev
In-Reply-To: <1143152153.4257.28.camel@localhost.localdomain>
Subject: powerpc: use guarded ioremap for cell on-chip mappings
I'm not sure where the information came from, but I assumed
that doing cache-inhibited mappings for mmio regions was
sufficient.
It seems we also need the guarded bit set, like everyone
else, which is the default for ioremap.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linus-2.6/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linus-2.6/arch/powerpc/platforms/cell/interrupt.c
@@ -226,9 +226,7 @@ static int setup_iic_hardcoded(void)
regs += 0x20;
printk(KERN_INFO "IIC for CPU %d at %lx\n", cpu, regs);
- iic->regs = __ioremap(regs, sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
-
+ iic->regs = ioremap(regs, sizeof(struct iic_regs));
iic->target_id = (nodeid << 4) + ((cpu & 1) ? 0xf : 0xe);
}
@@ -269,14 +267,12 @@ static int setup_iic(void)
}
iic = &per_cpu(iic, np[0]);
- iic->regs = __ioremap(regs[0], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[0], sizeof(struct iic_regs));
iic->target_id = ((np[0] & 2) << 3) + ((np[0] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[0], regs[0], iic->regs);
iic = &per_cpu(iic, np[1]);
- iic->regs = __ioremap(regs[2], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[2], sizeof(struct iic_regs));
iic->target_id = ((np[1] & 2) << 3) + ((np[1] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[1], regs[2], iic->regs);
Index: linus-2.6/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/iommu.c
+++ linus-2.6/arch/powerpc/platforms/cell/iommu.c
@@ -344,8 +344,8 @@ static int cell_map_iommu_hardcoded(int
/* node 0 */
iommu = &cell_iommus[0];
- iommu->mapped_base = __ioremap(0x20000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x20000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x20000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x20000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -357,8 +357,8 @@ static int cell_map_iommu_hardcoded(int
/* node 1 */
iommu = &cell_iommus[1];
- iommu->mapped_base = __ioremap(0x30000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x30000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x30000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x30000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -407,8 +407,8 @@ static int cell_map_iommu(void)
iommu->base = *base;
iommu->mmio_base = *mmio_base;
- iommu->mapped_base = __ioremap(*base, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(*mmio_base, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(*base, 0x1000);
+ iommu->mapped_mmio_base = ioremap(*mmio_base, 0x1000);
enable_mapping(iommu->mapped_base,
iommu->mapped_mmio_base);
Index: linus-2.6/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linus-2.6/arch/powerpc/platforms/cell/pervasive.c
@@ -203,7 +203,7 @@ found:
pr_debug("pervasive area for CPU %d at %lx, size %x\n",
cpu, real_address, size);
- p->regs = __ioremap(real_address, size, _PAGE_NO_CACHE);
+ p->regs = ioremap(real_address, size);
p->thread = thread;
return 0;
}
Index: linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -159,7 +159,7 @@ void spider_init_IRQ_hardcoded(void)
for (node = 0; node < num_present_cpus()/2; node++) {
spiderpic = pics[node];
printk(KERN_DEBUG "SPIDER addr: %lx\n", spiderpic);
- spider_pics[node] = __ioremap(spiderpic, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spiderpic, 0x800);
for (n = 0; n < IIC_NUM_EXT; n++) {
int irq = n + IIC_EXT_OFFSET + node * IIC_NODE_STRIDE;
get_irq_desc(irq)->handler = &spider_pic;
@@ -210,7 +210,7 @@ void spider_init_IRQ(void)
if ( n != 2)
printk("reg property with invalid number of elements \n");
- spider_pics[node] = __ioremap(spider_reg, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spider_reg, 0x800);
printk("SPIDER addr: %lx with %i addr_cells mapped to %p\n",
spider_reg, n, spider_pics[node]);
^ permalink raw reply
* [PATCH] powerpc: use guarded ioremap for on-chip mappings
From: Arnd Bergmann @ 2006-03-24 18:47 UTC (permalink / raw)
To: linuxppc-dev
Cc: stk, linux-kernel, Milton Miller, Paul Mackerras, hpenner,
Arnd Bergmann, cbe-oss-dev
In-Reply-To: <1143152153.4257.28.camel@localhost.localdomain>
Subject: powerpc: use guarded ioremap for cell on-chip mappings
I'm not sure where the information came from, but I assumed
that doing cache-inhibited mappings for mmio regions was
sufficient.
It seems we also need the guarded bit set, like everyone
else, which is the default for ioremap.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linus-2.6/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linus-2.6/arch/powerpc/platforms/cell/interrupt.c
@@ -226,9 +226,7 @@ static int setup_iic_hardcoded(void)
regs += 0x20;
printk(KERN_INFO "IIC for CPU %d at %lx\n", cpu, regs);
- iic->regs = __ioremap(regs, sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
-
+ iic->regs = ioremap(regs, sizeof(struct iic_regs));
iic->target_id = (nodeid << 4) + ((cpu & 1) ? 0xf : 0xe);
}
@@ -269,14 +267,12 @@ static int setup_iic(void)
}
iic = &per_cpu(iic, np[0]);
- iic->regs = __ioremap(regs[0], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[0], sizeof(struct iic_regs));
iic->target_id = ((np[0] & 2) << 3) + ((np[0] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[0], regs[0], iic->regs);
iic = &per_cpu(iic, np[1]);
- iic->regs = __ioremap(regs[2], sizeof(struct iic_regs),
- _PAGE_NO_CACHE);
+ iic->regs = ioremap(regs[2], sizeof(struct iic_regs));
iic->target_id = ((np[1] & 2) << 3) + ((np[1] & 1) ? 0xf : 0xe);
printk("IIC for CPU %d at %lx mapped to %p\n", np[1], regs[2], iic->regs);
Index: linus-2.6/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/iommu.c
+++ linus-2.6/arch/powerpc/platforms/cell/iommu.c
@@ -344,8 +344,8 @@ static int cell_map_iommu_hardcoded(int
/* node 0 */
iommu = &cell_iommus[0];
- iommu->mapped_base = __ioremap(0x20000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x20000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x20000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x20000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -357,8 +357,8 @@ static int cell_map_iommu_hardcoded(int
/* node 1 */
iommu = &cell_iommus[1];
- iommu->mapped_base = __ioremap(0x30000511000, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(0x30000510000, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(0x30000511000, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x30000510000, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -407,8 +407,8 @@ static int cell_map_iommu(void)
iommu->base = *base;
iommu->mmio_base = *mmio_base;
- iommu->mapped_base = __ioremap(*base, 0x1000, _PAGE_NO_CACHE);
- iommu->mapped_mmio_base = __ioremap(*mmio_base, 0x1000, _PAGE_NO_CACHE);
+ iommu->mapped_base = ioremap(*base, 0x1000);
+ iommu->mapped_mmio_base = ioremap(*mmio_base, 0x1000);
enable_mapping(iommu->mapped_base,
iommu->mapped_mmio_base);
Index: linus-2.6/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linus-2.6/arch/powerpc/platforms/cell/pervasive.c
@@ -203,7 +203,7 @@ found:
pr_debug("pervasive area for CPU %d at %lx, size %x\n",
cpu, real_address, size);
- p->regs = __ioremap(real_address, size, _PAGE_NO_CACHE);
+ p->regs = ioremap(real_address, size);
p->thread = thread;
return 0;
}
Index: linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -159,7 +159,7 @@ void spider_init_IRQ_hardcoded(void)
for (node = 0; node < num_present_cpus()/2; node++) {
spiderpic = pics[node];
printk(KERN_DEBUG "SPIDER addr: %lx\n", spiderpic);
- spider_pics[node] = __ioremap(spiderpic, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spiderpic, 0x800);
for (n = 0; n < IIC_NUM_EXT; n++) {
int irq = n + IIC_EXT_OFFSET + node * IIC_NODE_STRIDE;
get_irq_desc(irq)->handler = &spider_pic;
@@ -210,7 +210,7 @@ void spider_init_IRQ(void)
if ( n != 2)
printk("reg property with invalid number of elements \n");
- spider_pics[node] = __ioremap(spider_reg, 0x800, _PAGE_NO_CACHE);
+ spider_pics[node] = ioremap(spider_reg, 0x800);
printk("SPIDER addr: %lx with %i addr_cells mapped to %p\n",
spider_reg, n, spider_pics[node]);
^ permalink raw reply
* [PATCH] powerpc: fix spider-pic affinity setting
From: Arnd Bergmann @ 2006-03-24 18:46 UTC (permalink / raw)
To: linuxppc-dev
Cc: Milton Miller, linux-kernel, Paul Mackerras, Arnd Bergmann,
cbe-oss-dev
In-Reply-To: <200603241905.04356.arnd.bergmann@de.ibm.com>
As noticed by Milton Miller, setting the initial affinity in
spider-pic can go wrong if the target node field was not orinally
empty.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -88,7 +88,7 @@ static void spider_enable_irq(unsigned i
void __iomem *cfg = spider_get_irq_config(irq);
irq = spider_get_nr(irq);
- out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
+ out_be32(cfg, (in_be32(cfg) & ~0xf0)| 0x3107000eu | nodeid);
out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
}
^ permalink raw reply
* [PATCH] synclink_gt remove uneeded async code
From: Paul Fulghum @ 2006-03-24 18:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List
Remove code in async receive handling that serves
no purpose with new tty receive buffering.
Previously this code tried to free up receive buffer space,
but now does nothing useful while making expensive calls.
Signed-off-by: Paul Fulghum <paulkf@microgate.com>
--- linux-2.6.16/drivers/char/synclink_gt.c 2006-03-24 10:19:43.000000000 -0600
+++ b/drivers/char/synclink_gt.c 2006-03-24 10:21:42.000000000 -0600
@@ -1762,10 +1762,6 @@ static void rx_async(struct slgt_info *i
DBGDATA(info, p, count, "rx");
for(i=0 ; i < count; i+=2, p+=2) {
- if (tty && chars) {
- tty_flip_buffer_push(tty);
- chars = 0;
- }
ch = *p;
icount->rx++;
^ permalink raw reply
* [PATCH] powerpc: fix spider-pic affinity setting
From: Arnd Bergmann @ 2006-03-24 18:46 UTC (permalink / raw)
To: linuxppc-dev
Cc: Arnd Bergmann, Paul Mackerras, linux-kernel, Milton Miller,
cbe-oss-dev
In-Reply-To: <200603241905.04356.arnd.bergmann@de.ibm.com>
As noticed by Milton Miller, setting the initial affinity in
spider-pic can go wrong if the target node field was not orinally
empty.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--- linus-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linus-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -88,7 +88,7 @@ static void spider_enable_irq(unsigned i
void __iomem *cfg = spider_get_irq_config(irq);
irq = spider_get_nr(irq);
- out_be32(cfg, in_be32(cfg) | 0x3107000eu | nodeid);
+ out_be32(cfg, (in_be32(cfg) & ~0xf0)| 0x3107000eu | nodeid);
out_be32(cfg + 4, in_be32(cfg + 4) | 0x00020000u | irq);
}
^ permalink raw reply
* USB PCI problems on Ultra 5
From: Chris Boot @ 2006-03-24 18:45 UTC (permalink / raw)
To: sparclinux
Hi all,
I've been trying to add a PCI USB card to a Sun Ultra 5 workstation, and
I'm not naving much luck. Basically, I see two behaviours when the
machine boots up:
1. The machine doesn't even reach PROM (screen remains black).
2. The machine boots fine, but ignores the USB card and one of the other
PCI cards (usually the one in PCI slot 3).
Has anyone seen this sort of behaviour, let alone solved it?
It's a PCI card based on a VIA VT6212L chip, and works fine in the few
x86 PCs that I tried it in.
Many thanks,
Chris
PS: I'm not subscribed so please CC me.
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* xc_linux_save(): which context does it get invoked?
From: T S @ 2006-03-24 18:45 UTC (permalink / raw)
To: xen-users, xen-devel
In-Reply-To: <7f1eacdd0603240720g2dee921cyb6676b54ecd9cdc3@mail.gmail.com>
Hello,
Thanks to Ewan Mellor, I managed to get some understanding of the flow of
events when "xm save" is called. But I still don't understand which kernel
is doing what.
In my setup, i have the hypervisor and on top of it there is Dom-0 and a
Guest kernels running. From Dom-0, I invoke "xm save" on Guest. This results
in calling some python code which (A) waits in one thread to see in xenstore
'suspend' value for control/shutdown, and (B) calls xc_save() in another
thread. xc_save() calls xc_linux_save().
My question: Does (B) get executed in Dom-0 or Hyperviser? If I change
xc_linux_save.c, should I compile xen, xen0, or xenU kernel to see the
effect?
thanks,
- Ts
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* JFFS2 & NAND problem.
From: Han Chang @ 2006-03-24 18:44 UTC (permalink / raw)
To: linux-mtd
Hello,
I'm trying to get JFFS2 working on a NAND flash device. I'm having two
problems. They might be related.
1) Once I mount the JFFS2 to the device, I am able to create directory and
copy files into there. If I compare the files in the JFFS2 directory with
the original files. They are exactly match. Even if I do a "sync", and
compare them again, and they still match. But once I reboot the system and
compare the files in the JFFS2 directory with the original files, then they
are not matched any more. Anyone have seen this kind of behavior?
2) One thing I noticed when I mount the JFFS2 to the devive, there are bunch
of following CRC msgs dumped out. I have done other test on the NAND flash
and it's in good condition. I'm puzzled with these "CRC failed" msgs.
jffs2_get_inode_nodes(): CRC failed on node at 0x0005efd0: Read 0xffffffff,
calc
ulated 0x6791a538
jffs2_get_inode_nodes(): CRC failed on node at 0x0005e7d8: Read 0xffffffff,
calc
ulated 0x81c6885d
jffs2_get_inode_nodes(): CRC failed on node at 0x0004bff8: Read 0xffffffff,
calc
ulated 0xcfd1b4d3
jffs2_get_inode_nodes(): CRC failed on node at 0x00040fd4: Read 0xffffffff,
calc
ulated 0x596a66c5
jffs2_get_inode_nodes(): CRC failed on node at 0x0002d7e0: Read 0xffffffff,
calc
ulated 0xb6f7ff0d
jffs2_get_inode_nodes(): CRC failed on node at 0x00028fcc: Read 0xffffffff,
calc
ulated 0x78990f70
jffs2_get_inode_nodes(): CRC failed on node at 0x0001efcc: Read 0xffffffff,
calc
ulated 0x30a35bd1
jffs2_get_inode_nodes(): CRC failed on node at 0x0001dfe4: Read 0xffffffff,
calc
ulated 0x4f77e039
I appreciate any help!!!
Han
^ permalink raw reply
* [Bug 5553] speedstep-smi fails to load if CONFIG_CPU_FREQ_DEBUG is not set
From: bugme-daemon @ 2006-03-24 18:45 UTC (permalink / raw)
To: cpufreq
http://bugzilla.kernel.org/show_bug.cgi?id=5553
akpm@osdl.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |CODE_FIX
------- Additional Comments From akpm@osdl.org 2006-03-24 10:45 -------
Thanks for confirming. I'll send this in for 2.6.16.1 as well.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply
* Re: [uml-devel] Re: TLS support - status - need for re-testing
From: Blaisorblade @ 2006-03-24 18:44 UTC (permalink / raw)
To: Jeff Dike; +Cc: user-mode-linux-devel, Antoine Martin
In-Reply-To: <20060324173247.GD5400@ccure.user-mode-linux.org>
On Friday 24 March 2006 18:32, Jeff Dike wrote:
> On Fri, Mar 24, 2006 at 12:43:33PM +0100, Blaisorblade wrote:
> > We discussed this time ago, and read the description of the patch:
> > > global-ldt-sem - We should be using mutexes now, not semaphores
> >
> > That's your patch, but below I drop this.
>
> My patch predates mutexes.
>
> But you still use semaphores, and that should be updated.
We'll do it at some time, there's no hurry for that; or they'll do it anyway
before ripping out semaphores.
> It's simpler. A single global lock is simpler than a lock in every
> datastructure.
My only doubt (I'd almost swear it doesn't happen) is if two locks of two
different structures are ever taken. That would fail.
About locking, I've discovered that sigio_lock must use spin_lock_irqsave()
instead of spin_lock; currently with Mutex debugging I get hangs on that
spinlock, but on UP currently you get a race between process context and
interrupt context.
The failing case is when that lock is taken in process context, then an
interrupt is triggered whose handler takes again that. In fact, for mutual
exclusion between process context and irq context an spin_lock_irq{,save} is
_always_ recommended.
Only problem will be to check for sleepers in process context - there could be
many ones.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* why no option for 'ide=nocddma'?
From: Jack Howarth @ 2006-03-24 18:43 UTC (permalink / raw)
To: linux-kernel
It appears that the current Linux kernel still has trouble
verifying installation CDs for Fedora Core even in the FC5
release unless users pass the 'ide=nodma' kernel option. If
the problem with CDs using dma isn't going to be fully resolved,
why can't we have a 'ide=nocddma' kernel option that would only
apply to CD/DVD drives? The current situation is unfortunate
because installations end up with 'ide=nodma' in grub.conf
which severely slows down disk i/o. Thanks in advance for
any information on this issue.
Jack
ps Does this issue with dma and CD/DVD drives only apply to reads
or are writes effected as well?
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Andreas Ericsson @ 2006-03-24 18:40 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne28b3a.cp6.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>
>
>>>I'm not sure what the best "object that's not supposed to be there" is.
>>
>>.git/objects/00/hoping-for-a-404-or-webadmin-should-fix
>
>
> If .git/objects/00/00000000000000000000000000000000000000 exists, the
> repository has big problems already.
>
Indeed. I'm off sobriety again, it being friday and all, but I'm
assuming there are more than 18 zeroes there, yes? The "feature" of the
above line is that it will fit in any buffer that already exists, and
will match any third argument to send(2) that already exists.
> (Aside: `C-u 38 0' doesn't work because Emacs hears `C-u 380' and waits
> for a key. `M-: (insert-char ?0 38) RET' does the right thing, but is
> ugly. Any better suggestions?)
>
This I happily don't understand at all. I'm also happy ignorant of what
it has to do with the issue at hand.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Bug encountered while comitting
From: Matthias Kestenholz @ 2006-03-24 18:39 UTC (permalink / raw)
To: git
Hello list,
I don't know if this is the right place to report a bug, but I'll
just try and see what comes back.
I am trying to build a Wiki [1] using PHP, a hacked version of Markdown,
and git for content tracking. I use the git core plumbing to do the
history work.
The PHP script created directories under .git/objects which were
only writable by www-data. There were other directories which were
owned by user mk and group www-data, and they were group writable.
So, I had write access to only a part of the .git directory.
When I tried to commit, I got a message saying "Unable to write sha1
filename".
The result was, that only part of the commit was recorded and that I
experienced repository corruption. refs/heads/master pointed to a
non-existant object.
The expected behavior would have been an error message telling me I
had insufficient write privileges and surely no repository
corruption.
Thanks,
Matthias
[1]: http://spinlock.ch/cgi-bin/gitweb.pl?p=swisdk2/bugs.git;a=tree
(See Wiki_ctrl.php for source)
--
:wq
^ 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.