* Re: Problem with dependencies in packages
From: Graham Gower @ 2011-02-14 0:29 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTikP8CNgvex==mnJY8McTouY0n-QzcUQjaFZRV8X@mail.gmail.com>
On 14 February 2011 09:20, Filip Zyzniewski <filip.zyzniewski@gmail.com> wrote:
> Hi,
>
> I think I have found a problem with versioned dependencies (or I don't
> unserstand something).
>
> I am trying to switch the jlime distribution from ipk to deb packages.
> When debugging do_rootfs problems I stumbled upon this:
>
> The following packages have unmet dependencies:
> libncursesw5: Depends: libtinfo5 (>= 5.7+20110115) but 5.7-r16 is to
> be installed
> E: Broken packages
>
> The Depends line in deb package control file comes from
> classes/package_deb.bbclass:do_package_deb():
>
> rdepends = explode_deps(unicode(bb.data.getVar("RDEPENDS", localdata, 1) or ""))
> [...]
> ctrlfile.write(u"Depends: %s\n" % ", ".join(rdepends))
>
>
> The dependency string comes from classes/package.bbclass:766:
> dep = "%s (>= %s)" % (dep_pkg, ver_needed)
>
> ver_needed comes (in case of ncurses) from .ver files in the build
> tree, generated by the same function a bit earlier using pkgver
> variable set in lines 657-661:
>
> pkgver = bb.data.getVar('PKGV_' + pkg, d, True)
> if not pkgver:
> pkgver = bb.data.getVar('PV_' + pkg, d, True)
> if not pkgver:
> pkgver = ver
>
> and in ncurses_5.7.bb we have:
>
> PATCHDATE = "20110115"
> PKGV = "${PV}+${PATCHDATE}"
>
>
> Isn't this an incosistency that ncurses_5.7-r16 depends on
> libtinfo5_5.7+20110115 ? Shouldn't it depend on libtinfo5_5.7-r16?
Probably.
> What's the reason for this situation? Does opkg somehow compare these
> versions in another way causing the problem to be invisible?
Opkg uses the same version comparison as dpkg. In fact, the
verrevcmp() code in opkg was copied verbatim from dpkg. The ascii
values of '+' and '-' are compared, with '+' being lower than '-'.
# opkg compare-versions 5.7-r16 ">=" 5.7+20110115
# echo $?
0
So, 5.7-r16 would be expected to satisfy the dependency in this case.
I am unsure why the version comparison fails for you... maybe the dpkg
comparison code has been changed since it was copied into ipkg?
> bye,
> Filip Zyzniewski
-Graham
^ permalink raw reply
* [PATCH v3 2/5] ARM: pm: add generic CPU suspend/resume support
From: Kukjin Kim @ 2011-02-14 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211115853.GC23404@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
>
> On Wed, Feb 09, 2011 at 07:15:25PM -0800, Colin Cross wrote:
> > The diagnostic register also needs to be saved to keep the errata bits
> > set in __v7_setup.
>
> Saving I've no problem with. Restoring gets hairy with kernels running
> in non-secure mode, as we can't just write the register - we don't know
> whether we are running in secure or non-secure mode. A write to the
> register in NS mode will crash.
>
> Santosh: is the diagnostic register on OMAP4 re-initialized by the secure
> code on OMAP?
>
> > > + stmia r0, {r4 - r11}
> > > + ldmfd sp!, {r4 - r11, pc}
> > > +ENDPROC(cpu_v7_do_suspend)
> > > +
> > > +ENTRY(cpu_v7_do_resume)
> > > + mov ip, #0
> > > + mcr p15, 0, ip, c8, c7, 0 @ invalidate TLBs
> > > + mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache
> >
> > Does this need the same ALT_SMP/ALT_UP combo as v7_flush_icache_all?
>
> That depends whether you the CPU which is resuming is part of a coherent
> SMP system at that point. This instruction will invalidate the I-cache
> for the local CPU only, whereas the c7, c1 variant will invalidate the
> instruction caches of all CPUs within the inner sharable domain.
>
> Has anything changed in the other CPUs as a result of this CPU resuming
> at this point? I don't think so, so I think we just need to ensure that
> the local CPU instruction cache is invalidated at this point.
>
> > Tegra2 suspend and cpuidle works on top of this patch and the patch
> > that adds SMP support to sleep_save_sp. Tegra seems to need to
> > invalidate the entire l1 data cache before enabling it,
>
> As it's undefined what state the data cache is in on resume, I'm surprised
> the s5pv210 code doesn't also need a D-cache invalidate too. Maybe Samsung
> folk can answer that.
>
Now, it works fine with omission D-cache invalidate on S5PV210. Basically, Samsung S5P SoCs have some kind of hardware initialization code. So I'm not sure it has something for it, will/need to check it to hardware guys soon :) Then let you know about that ;)
As a note, I will test your updated generic CPU suspend/resume support on Samsung SoCs also, if any available branch which has p2v patches for it, please let me know. Anyway sorry for late testing on board.
Have a nice weekend.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Fwd: v4l2 lost frame when use with epoll (uvc bug)
From: xinglp @ 2011-02-14 0:25 UTC (permalink / raw)
To: linux-media; +Cc: laurent.pinchart
---------- Forwarded message ----------
From: Hans Verkuil <hverkuil@xs4all.nl>
Date: 2011/2/13
Subject: Re: v4l2 lost frame when use with epoll
To: xinglp <xinglp@gmail.com>
抄送： bill@thedirks.org
On Sunday, February 13, 2011 13:33:27 xinglp wrote:
> 2011/2/13 Hans Verkuil <hverkuil@xs4all.nl>:
> > On Sunday, February 13, 2011 09:18:41 xinglp wrote:
> >> It seems like that epoll_wait() do not return as soon as possible when one
> >> frame be captured, it only returns when 4(set by ioctl(..VIDIOC_REQBUFS..).)
> >> frames be captured.
> >> And v4l2_buffer::sequence indecates one lost per 4 frames.
> >
> > What hardware/driver are you using?
> I' using uvcvideo. I've tried two cheap usbcam at two PC.
>
> lsusb
> Bus 002 Device 002: ID 1871:01f0 Aveo Technology Corp.
>
> lsmod
> Module Size Used by
> uvcvideo 54924 -
> videodev 65184 -
>
> DG45ID mainboard and a hp2530p notebook.
A quick follow-up: I could reproduce this with uvc. It works fine with vivi
and gspca, so this seems to be a uvc bug.
Please post this bug report to the linux-media mailinglist with a CC to
Laurent Pinchart <laurent.pinchart@ideasonboard.com> who is the uvc maintainer.
Regards,
Hans
>
> >> The source in attachment can reproducte it, run it with option --epoll
> >> to make it use epoll.
> >>
> >> The attachment is a modified version of the follow URL.
> >> http://v4l2spec.bytesex.org/v4l2spec/capture.c
> >>
> >
> > I can't reproduce this with the vivi driver. It's much more likely to be a
> > driver issue.
> On my machine, vivi even not work with epoll(). only capture one frame
> and stop.(epoll_wait() never return again.)
>
> >
> > BTW, it's much better to mail the linux-media mailinglist. Also note that Bill
> > is no longer involved in V4L.
> I can't subscribe any kernel maillist successfully.
>
> > Regards,
> >
> > Hans
> >
> > --
> > Hans Verkuil - video4linux developer - sponsored by Cisco
> >
>
>
--
Hans Verkuil - video4linux developer - sponsored by Cisco
^ permalink raw reply
* Re: [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Chris Ball @ 2011-02-14 0:25 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Shawn Guo, s.hauer, LW, linux-mmc, linux-arm-kernel
In-Reply-To: <201102132335.54868.arnd@arndb.de>
Hi Arnd,
On Sun, Feb 13, 2011 at 11:35:54PM +0100, Arnd Bergmann wrote:
> > Please add a Reviewed-by: from Arnd and a Tested-by: from Lothar.
> > Could you add a MODULE_AUTHOR() field, too?
>
> In general, these tags should not simply be added by the author without
> having the person who did the reviewing or testing specifically provide
> them!
>
> In this particular case, I'm happy with the driver in version 2, good job!
> Please do add my
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Ah, okay, sorry. I do behave that way with S-o-b, but in this case I
wanted to make sure people who put effort into reviewing/testing didn't
go uncredited -- next time I'll send mail to the reviewer/tester
reminding them to add a tag if they're happy.
Thanks,
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH v2 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Chris Ball @ 2011-02-14 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102132335.54868.arnd@arndb.de>
Hi Arnd,
On Sun, Feb 13, 2011 at 11:35:54PM +0100, Arnd Bergmann wrote:
> > Please add a Reviewed-by: from Arnd and a Tested-by: from Lothar.
> > Could you add a MODULE_AUTHOR() field, too?
>
> In general, these tags should not simply be added by the author without
> having the person who did the reviewing or testing specifically provide
> them!
>
> In this particular case, I'm happy with the driver in version 2, good job!
> Please do add my
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Ah, okay, sorry. I do behave that way with S-o-b, but in this case I
wanted to make sure people who put effort into reviewing/testing didn't
go uncredited -- next time I'll send mail to the reviewer/tester
reminding them to add a tag if they're happy.
Thanks,
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: return proper error if clk_get fails
From: Kyungmin Park @ 2011-02-14 0:19 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Ben Dooks, Paul Mundt, linux-fbdev
In-Reply-To: <1297414270.14046.1.camel@mola>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
On Fri, Feb 11, 2011 at 5:51 PM, Axel Lin <axel.lin@gmail.com> wrote:
> Return PTR_ERR(sfb->bus_clk) instead of 0 if clk_get fails.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/s3c-fb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 83ce9a0..6817d18 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1340,6 +1340,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> sfb->bus_clk = clk_get(dev, "lcd");
> if (IS_ERR(sfb->bus_clk)) {
> dev_err(dev, "failed to get bus clock\n");
> + ret = PTR_ERR(sfb->bus_clk);
> goto err_sfb;
> }
>
> --
> 1.7.2
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: return proper error if clk_get fails
From: Kyungmin Park @ 2011-02-14 0:19 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, Ben Dooks, Paul Mundt, linux-fbdev
In-Reply-To: <1297414270.14046.1.camel@mola>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
On Fri, Feb 11, 2011 at 5:51 PM, Axel Lin <axel.lin@gmail.com> wrote:
> Return PTR_ERR(sfb->bus_clk) instead of 0 if clk_get fails.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/s3c-fb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 83ce9a0..6817d18 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1340,6 +1340,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> sfb->bus_clk = clk_get(dev, "lcd");
> if (IS_ERR(sfb->bus_clk)) {
> dev_err(dev, "failed to get bus clock\n");
> + ret = PTR_ERR(sfb->bus_clk);
> goto err_sfb;
> }
>
> --
> 1.7.2
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH 0/4] Prepare mdadm for migrations (external meta)
From: NeilBrown @ 2011-02-14 0:17 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110210134710.9276.91430.stgit@gklab-128-013.igk.intel.com>
On Thu, 10 Feb 2011 14:55:53 +0100 Adam Kwolek <adam.kwolek@intel.com> wrote:
> This few patches prepares mdadm for level and chunk size migration using external metadata.
> 1. FIX: delta_disk can have UnSet value
> A while ago I've reported problem that delta_disks can have UnSet value, so adding it
> to raid_disks can produce error in mdadm. Looking my first patch you proposed
> to address this problem by changing reshape_super() interface rather than
> set condition on function call. This patch implements your idea.
>
> 2. FIX: Get spares from external metadata
> imsm: FIX: Add spare disks information to array description
> Those 2 patches addresses problem with not initializes spares counter in mdinfo
> using external metadata.
>
> 3. FIX: Add raid5 to raid0 case to analyse_change()
> This patch adds missing of level transition in Grow.c
I've applied all of these though I changed the last one to:
--- a/Grow.c
+++ b/Grow.c
@@ -1056,6 +1056,7 @@ char *analyse_change(struct mdinfo *info, struct reshape *re)
info->array.layout = ALGORITHM_PARITY_N;
case 5:
switch (info->new_level) {
+ case 0:
case 4:
re->level = info->array.level;
re->before.data_disks = info->array.raid_disks - 1;
as I think that is all that is required.
Thanks,
NeilBrown
>
> This series should be applied on devel-3.2 branch with my yesterday's 4 patches
>
> BR
> Adam
>
> ---
>
> Adam Kwolek (4):
> FIX: Add raid5 to raid0 case to analyse_change()
> imsm: FIX: Add spare disks information to array description
> FIX: Get spares from external metadata
> FIX: delta_disk can have UnSet value
>
>
> Grow.c | 36 ++++++++++++++++++++++++++++++------
> mdadm.h | 3 ++-
> super-intel.c | 14 +++++++++++++-
> 3 files changed, 45 insertions(+), 8 deletions(-)
>
^ permalink raw reply
* Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
From: Andy Walls @ 2011-02-14 0:16 UTC (permalink / raw)
To: Devin Heitmueller, Mark Zimmerman; +Cc: linux-media
In-Reply-To: <1297632410.2401.6.camel@localhost>
On Sun, 2011-02-13 at 16:26 -0500, Andy Walls wrote:
> On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote:
> > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote:
> > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote:
> > > > Clearly my previous bisection went astray; I think I have a more
> > > > sensible result this time.
> > > >
> > > > qpc$ git bisect good
> > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit
> > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be
> > > > Author: Jean Delvare <khali@linux-fr.org>
> > > > Date: ? Sun Jul 18 16:52:05 2010 -0300
> > > >
> > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions
> > > >
> > > > ? ?Don't just check for nacks on zero-length transactions. Check on
> > > > ? ?other transactions too.
> > >
> > > This could be a combination of the xc5000 doing clock stretching and
> > > the cx23885 i2c master not properly implementing clock stretch. In
> > > the past I've seen i2c masters broken in their handling of clock
> > > stretching where they treat it as a NAK.
> > >
> > > The xc5000 being one of the few devices that actually does i2c clock
> > > stretching often exposes cases where it is improperly implemented in
> > > the i2c master driver (I've had to fix this with several bridges).
> > >
Devin,
I just checked. The CX23885 driver *is* setting up to allow slaves to
stretch the clock.
By analysis, I have confirmed that Jean's sugguested patch that I moved
forward was wrong for the hardware's behavior. When the cx23885 I2C
routines decide to set the I2C_EXTEND flag (and maybe the I2C_NOSTOP
flag), we most certainly should *not* be expecting an ACK from the
particular hardware register. The original commit should certainly be
reverted.
Checking for slave ACK/NAK will need to be done with a little more care;
so for now, I'll settle for ignoring them.
Regards,
Andy
^ permalink raw reply
* [PATCH 1/5] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Shawn Guo @ 2011-02-14 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19794.19192.351501.395360@ipc1.ka-ro>
On Wed, Feb 09, 2011 at 09:06:16AM +0100, Lothar Wa?mann wrote:
> Hi Shawn,
>
> Shawn Guo writes:
> > On Tue, Feb 08, 2011 at 03:41:55PM +0100, Lothar Wa?mann wrote:
> [...]
> > > What's behinde the 'PIO' transfers is programming controller registers
> > > via DMA along with the actual DMA data transfer. DMA_NONE simply
> > > means, that the DMA transfer does only the register programming but
> > > does not transfer any payload. The 'pio_words' are the values that are
> > > being written to consecutive locations of e.g. the SPI controller
> > > register address space.
> > > The programming is actually done by DMA, in any case.
> > >
> > I'm waiting for this reply ;)
> >
> > i.MX23/28 Reference Manual uses word "PIO" for the working mode that
> > Lothar has explained. It seems that "PIO" in mxs-dma needs some more
> > documents.
> >
> > It's true that mxs dma hardware is designed to program peripheral
> > registers along with data transfer with ccw chain. But it's hard
> > for generic dmaengine model to implement that. The client device
> > driver gets the data in scatter-gather list to transfer. It requires
> > client driver to manipulate the sgl to get pio ccw inserted properly
> > to get the "along with" implemented. This is not a reasonable
> > implementation to me.
> >
> > I still chose to keep the pio mode in the implementation in "single
> > step" rather than "along with" way. That means client driver has to
> > issue one dma request to program client device registers, and issue
> > another one to transfer data. The natural thought is that the pio
> >
> which defeats the purpose of the whole thing. If the software has to
> issue a single request for DMA to program the registers it could as
> well directly write the registers without any DMA. The purpose of the
> embedded 'PIO' transfers is, that you can set up a whole chain of
> commands and associated data transfers and have that executed
> without any further software intervention.
>
I'm redefining the flags of dma prep function as whether the current
sg list should be appended to the last one in the ccw chain, so that
data transfer can be done along with pio controller register. Please
see mxs-dma v2 coming soon for details.
Regards,
Shawn
> > support can totally be saved with cpu programming. But looking at
> > any mxs dma client device in reference manual, you will find it gets
> > two irq lines, irq_dma and irq_error. For ssp (mmc) example, when
> > one mmc command is issued and completed without error, you have to
> > either polling ssp status register or use pio dma and irq_dma
> > interrupt to know the completion. That's to say I keep the pio
> >
> You could use the SSP IRQ as well.
>
>
> Lothar Wa?mann
> --
> ___________________________________________________________
>
> Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Gesch?ftsf?hrer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.de | info at karo-electronics.de
> ___________________________________________________________
>
^ permalink raw reply
* Re: [PATCH V2 0/3] drivers/staging: zcache: dynamic page cache/swap compression
From: Matt @ 2011-02-14 0:08 UTC (permalink / raw)
To: Dan Magenheimer
Cc: gregkh, Chris Mason, akpm, torvalds, matthew, linux-kernel,
linux-mm, ngupta, jeremy, Kurt Hackel, npiggin, riel, Konrad Wilk,
mel, minchan.kim, kosaki.motohiro, sfr, wfg, tytso, viro, hughd,
hannes
In-Reply-To: <1ddd01a8-591a-42bc-8bb3-561843b31acb@default>
On Wed, Feb 9, 2011 at 1:03 AM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
[snip]
>
> If I've missed anything important, please let me know!
>
> Thanks again!
> Dan
>
Hi Dan,
thank you so much for answering my email in such detail !
I shall pick up on that mail in my next email sending to the mailing list :)
currently I've got a problem with btrfs which seems to get triggered
by cleancache get-operations:
Feb 14 00:37:19 lupus kernel: [ 2831.297377] device fsid
354120c992a00761-5fa07d400126a895 devid 1 transid 7
/dev/mapper/portage
Feb 14 00:37:19 lupus kernel: [ 2831.297698] btrfs: enabling disk space caching
Feb 14 00:37:19 lupus kernel: [ 2831.297700] btrfs: force lzo compression
Feb 14 00:37:19 lupus kernel: [ 2831.315844] zcache: created ephemeral
tmem pool, id=3
Feb 14 00:39:20 lupus kernel: [ 2951.853188] BUG: unable to handle
kernel paging request at 0000000001400050
Feb 14 00:39:20 lupus kernel: [ 2951.853219] IP: [<ffffffff8133ef1b>]
btrfs_encode_fh+0x2b/0x120
Feb 14 00:39:20 lupus kernel: [ 2951.853242] PGD 0
Feb 14 00:39:20 lupus kernel: [ 2951.853251] Oops: 0000 [#1] PREEMPT SMP
Feb 14 00:39:20 lupus kernel: [ 2951.853275] last sysfs file:
/sys/devices/platform/coretemp.3/temp1_input
Feb 14 00:39:20 lupus kernel: [ 2951.853295] CPU 4
Feb 14 00:39:20 lupus kernel: [ 2951.853303] Modules linked in: radeon
ttm drm_kms_helper cfbcopyarea cfbimgblt cfbfillrect ipt_REJECT
ipt_LOG xt_limit xt_tcpudp xt_state nf_nat_irc nf_conntrack_irc
nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp
iptable_filter ipt_addrtype xt_DSCP xt_dscp xt_iprange ip_tables
ip6table_filter xt_NFQUEUE xt_owner xt_hashlimit xt_conntrack xt_mark
xt_multiport xt_connmark nf_conntrack xt_string ip6_tables x_tables
it87 hwmon_vid coretemp snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
snd_timer snd soundcore i2c_i801 wmi e1000e shpchp snd_page_alloc
libphy e1000 scsi_wait_scan sl811_hcd ohci_hcd ssb usb_storage
ehci_hcd [last unloaded: tg3]
Feb 14 00:39:20 lupus kernel: [ 2951.853682]
Feb 14 00:39:20 lupus kernel: [ 2951.853690] Pid: 11394, comm:
btrfs-transacti Not tainted 2.6.37-plus_v16_zcache #4 FMP55/ipower
G3710
Feb 14 00:39:20 lupus kernel: [ 2951.853725] RIP:
0010:[<ffffffff8133ef1b>] [<ffffffff8133ef1b>]
btrfs_encode_fh+0x2b/0x120
Feb 14 00:39:20 lupus kernel: [ 2951.853751] RSP:
0018:ffff880129a11b00 EFLAGS: 00010246
Feb 14 00:39:20 lupus kernel: [ 2951.853767] RAX: 00000000000000ff
RBX: ffff88014a1ce628 RCX: 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853788] RDX: ffff880129a11b3c
RSI: ffff880129a11b70 RDI: 0000000000000006
Feb 14 00:39:20 lupus kernel: [ 2951.853808] RBP: 0000000001400000
R08: ffffffff8133eef0 R09: ffff880129a11c68
Feb 14 00:39:20 lupus kernel: [ 2951.853829] R10: 0000000000000001
R11: 0000000000000001 R12: ffff88014a1ce780
Feb 14 00:39:20 lupus kernel: [ 2951.853849] R13: ffff88021fefc000
R14: ffff88021fef9000 R15: 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853870] FS:
0000000000000000(0000) GS:ffff8800bf500000(0000)
knlGS:0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853894] CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
Feb 14 00:39:20 lupus kernel: [ 2951.853911] CR2: 0000000001400050
CR3: 0000000001c27000 CR4: 00000000000006e0
Feb 14 00:39:20 lupus kernel: [ 2951.853932] DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853952] DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
Feb 14 00:39:20 lupus kernel: [ 2951.853973] Process btrfs-transacti
(pid: 11394, threadinfo ffff880129a10000, task ffff880202e4ac40)
Feb 14 00:39:20 lupus kernel: [ 2951.853999] Stack:
Feb 14 00:39:20 lupus kernel: [ 2951.854006] ffff880129a11b50
ffff880000000003 ffff88003c60a098 0000000000000003
Feb 14 00:39:20 lupus kernel: [ 2951.854035] ffffffffffffffff
ffffffff810e6aaa 0000000000000000 0000000602e4ac40
Feb 14 00:39:20 lupus kernel: [ 2951.854063] ffffffff8133e3f0
ffffffff810e6cee 0000000000001000 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.854092] Call Trace:
Feb 14 00:39:20 lupus kernel: [ 2951.854103] [<ffffffff810e6aaa>] ?
cleancache_get_key+0x4a/0x60
Feb 14 00:39:20 lupus kernel: [ 2951.854122] [<ffffffff8133e3f0>] ?
btrfs_wake_function+0x0/0x20
Feb 14 00:39:20 lupus kernel: [ 2951.854140] [<ffffffff810e6cee>] ?
__cleancache_flush_inode+0x3e/0x70
Feb 14 00:39:20 lupus kernel: [ 2951.854161] [<ffffffff810b34d2>] ?
truncate_inode_pages_range+0x42/0x440
Feb 14 00:39:20 lupus kernel: [ 2951.854182] [<ffffffff812f115e>] ?
btrfs_search_slot+0x89e/0xa00
Feb 14 00:39:20 lupus kernel: [ 2951.854201] [<ffffffff810c3a45>] ?
unmap_mapping_range+0xc5/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854220] [<ffffffff810b3930>] ?
truncate_pagecache+0x40/0x70
Feb 14 00:39:20 lupus kernel: [ 2951.854240] [<ffffffff813458b1>] ?
btrfs_truncate_free_space_cache+0x81/0xe0
Feb 14 00:39:20 lupus kernel: [ 2951.854261] [<ffffffff812fce15>] ?
btrfs_write_dirty_block_groups+0x245/0x500
Feb 14 00:39:20 lupus kernel: [ 2951.854283] [<ffffffff812fcb6a>] ?
btrfs_run_delayed_refs+0x1ba/0x220
Feb 14 00:39:20 lupus kernel: [ 2951.854304] [<ffffffff8130afff>] ?
commit_cowonly_roots+0xff/0x1d0
Feb 14 00:39:20 lupus kernel: [ 2951.854323] [<ffffffff8130c583>] ?
btrfs_commit_transaction+0x363/0x760
Feb 14 00:39:20 lupus kernel: [ 2951.854344] [<ffffffff81067ea0>] ?
autoremove_wake_function+0x0/0x30
Feb 14 00:39:20 lupus kernel: [ 2951.854364] [<ffffffff81305bc3>] ?
transaction_kthread+0x283/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854383] [<ffffffff81305940>] ?
transaction_kthread+0x0/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854401] [<ffffffff81305940>] ?
transaction_kthread+0x0/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854420] [<ffffffff81067a16>] ?
kthread+0x96/0xa0
Feb 14 00:39:20 lupus kernel: [ 2951.854437] [<ffffffff81003514>] ?
kernel_thread_helper+0x4/0x10
Feb 14 00:39:20 lupus kernel: [ 2951.854455] [<ffffffff81067980>] ?
kthread+0x0/0xa0
Feb 14 00:39:20 lupus kernel: [ 2951.854471] [<ffffffff81003510>] ?
kernel_thread_helper+0x0/0x10
Feb 14 00:39:20 lupus kernel: [ 2951.854488] Code: 55 b8 ff 00 00 00
53 48 89 fb 48 83 ec 18 48 8b 6f 10 8b 3a 83 ff 04 0f 86 d5 00 00 00
85 c9 0f 95 c1 83 ff 07 0f 86 d5 00 00 00 <48> 8b 45 50 bf 05 00 00 00
48 89 06 84 c9 48 8b 85 68 fe ff ff
Feb 14 00:39:20 lupus kernel: [ 2951.854742] RIP [<ffffffff8133ef1b>]
btrfs_encode_fh+0x2b/0x120
Feb 14 00:39:20 lupus kernel: [ 2951.854762] RSP <ffff880129a11b00>
Feb 14 00:39:20 lupus kernel: [ 2951.854773] CR2: 0000000001400050
Feb 14 00:39:20 lupus kernel: [ 2951.860906] ---[ end trace
f831c5ceeaa49287 ]---
in my case I had compress-force with lzo and disk_cache enabled
another user of the kernel I'm currently running has had the same
problem with zcache
(http://forums.gentoo.org/viewtopic-p-6571799.html#6571799)
(looks like in his case compression and any other fancy additional
features weren't enabled)
changes made by this kernel or patchset to btrfs are from
* io-less dirty throttling patchset (44 patches)
* zcache V2 ("[PATCH] staging: zcache: fix memory leak" should be
applied in both cases)
* PATCH] fix (latent?) memory corruption in btrfs_encode_fh()
* btrfs-unstable changes to state of
3a90983dbdcb2f4f48c0d771d8e5b4d88f27fae6 (so practically equals btrfs
from 2.6.38-rc4+)
I haven't tried downgrading to vanilla 2.6.37 with zcache only, yet,
but kind of upgraded btrfs to the latest state of the btrfs-unstable
repository (http://git.eu.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=summary)
namely 3a90983dbdcb2f4f48c0d771d8e5b4d88f27fae6
this also didn't help and seemed to produce the same error-message
so to summarize:
1) error message appearing with all 4 patchsets applied changing
btrfs-code and compress-force=lzo and disk_cache enabled
2) error message appearing with default mount-options and btrfs from
2.6.37 and changes for zcache & io-less dirty throttling patchset
applied (first 2 patch(sets)) from list)
in my case I tried to extract / play back a 1.7 GiB tarball of my
portage-directory (lots of small files and some tar.bzip2 archives)
via pbzip2 or 7z when the error happened and the message was shown
Due to KMS sound (webradio streaming) was still running but I couldn't
continue work (X switching to kernel output) so I did the magic sysrq
combo (reisub)
Does that BUG message ring a bell for anyone ?
(if I should leave out anyone from the CC in the next emails or
future, please holler - I don't want to spam your inboxes)
Thanks
Matt
^ permalink raw reply
* Re: [PATCH V2 0/3] drivers/staging: zcache: dynamic page cache/swap compression
From: Matt @ 2011-02-14 0:08 UTC (permalink / raw)
To: Dan Magenheimer
Cc: gregkh, Chris Mason, akpm, torvalds, matthew, linux-kernel,
linux-mm, ngupta, jeremy, Kurt Hackel, npiggin, riel, Konrad Wilk,
mel, minchan.kim, kosaki.motohiro, sfr, wfg, tytso, viro, hughd,
hannes
In-Reply-To: <1ddd01a8-591a-42bc-8bb3-561843b31acb@default>
On Wed, Feb 9, 2011 at 1:03 AM, Dan Magenheimer
<dan.magenheimer@oracle.com> wrote:
[snip]
>
> If I've missed anything important, please let me know!
>
> Thanks again!
> Dan
>
Hi Dan,
thank you so much for answering my email in such detail !
I shall pick up on that mail in my next email sending to the mailing list :)
currently I've got a problem with btrfs which seems to get triggered
by cleancache get-operations:
Feb 14 00:37:19 lupus kernel: [ 2831.297377] device fsid
354120c992a00761-5fa07d400126a895 devid 1 transid 7
/dev/mapper/portage
Feb 14 00:37:19 lupus kernel: [ 2831.297698] btrfs: enabling disk space caching
Feb 14 00:37:19 lupus kernel: [ 2831.297700] btrfs: force lzo compression
Feb 14 00:37:19 lupus kernel: [ 2831.315844] zcache: created ephemeral
tmem pool, id=3
Feb 14 00:39:20 lupus kernel: [ 2951.853188] BUG: unable to handle
kernel paging request at 0000000001400050
Feb 14 00:39:20 lupus kernel: [ 2951.853219] IP: [<ffffffff8133ef1b>]
btrfs_encode_fh+0x2b/0x120
Feb 14 00:39:20 lupus kernel: [ 2951.853242] PGD 0
Feb 14 00:39:20 lupus kernel: [ 2951.853251] Oops: 0000 [#1] PREEMPT SMP
Feb 14 00:39:20 lupus kernel: [ 2951.853275] last sysfs file:
/sys/devices/platform/coretemp.3/temp1_input
Feb 14 00:39:20 lupus kernel: [ 2951.853295] CPU 4
Feb 14 00:39:20 lupus kernel: [ 2951.853303] Modules linked in: radeon
ttm drm_kms_helper cfbcopyarea cfbimgblt cfbfillrect ipt_REJECT
ipt_LOG xt_limit xt_tcpudp xt_state nf_nat_irc nf_conntrack_irc
nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp
iptable_filter ipt_addrtype xt_DSCP xt_dscp xt_iprange ip_tables
ip6table_filter xt_NFQUEUE xt_owner xt_hashlimit xt_conntrack xt_mark
xt_multiport xt_connmark nf_conntrack xt_string ip6_tables x_tables
it87 hwmon_vid coretemp snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm
snd_timer snd soundcore i2c_i801 wmi e1000e shpchp snd_page_alloc
libphy e1000 scsi_wait_scan sl811_hcd ohci_hcd ssb usb_storage
ehci_hcd [last unloaded: tg3]
Feb 14 00:39:20 lupus kernel: [ 2951.853682]
Feb 14 00:39:20 lupus kernel: [ 2951.853690] Pid: 11394, comm:
btrfs-transacti Not tainted 2.6.37-plus_v16_zcache #4 FMP55/ipower
G3710
Feb 14 00:39:20 lupus kernel: [ 2951.853725] RIP:
0010:[<ffffffff8133ef1b>] [<ffffffff8133ef1b>]
btrfs_encode_fh+0x2b/0x120
Feb 14 00:39:20 lupus kernel: [ 2951.853751] RSP:
0018:ffff880129a11b00 EFLAGS: 00010246
Feb 14 00:39:20 lupus kernel: [ 2951.853767] RAX: 00000000000000ff
RBX: ffff88014a1ce628 RCX: 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853788] RDX: ffff880129a11b3c
RSI: ffff880129a11b70 RDI: 0000000000000006
Feb 14 00:39:20 lupus kernel: [ 2951.853808] RBP: 0000000001400000
R08: ffffffff8133eef0 R09: ffff880129a11c68
Feb 14 00:39:20 lupus kernel: [ 2951.853829] R10: 0000000000000001
R11: 0000000000000001 R12: ffff88014a1ce780
Feb 14 00:39:20 lupus kernel: [ 2951.853849] R13: ffff88021fefc000
R14: ffff88021fef9000 R15: 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853870] FS:
0000000000000000(0000) GS:ffff8800bf500000(0000)
knlGS:0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853894] CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
Feb 14 00:39:20 lupus kernel: [ 2951.853911] CR2: 0000000001400050
CR3: 0000000001c27000 CR4: 00000000000006e0
Feb 14 00:39:20 lupus kernel: [ 2951.853932] DR0: 0000000000000000
DR1: 0000000000000000 DR2: 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.853952] DR3: 0000000000000000
DR6: 00000000ffff0ff0 DR7: 0000000000000400
Feb 14 00:39:20 lupus kernel: [ 2951.853973] Process btrfs-transacti
(pid: 11394, threadinfo ffff880129a10000, task ffff880202e4ac40)
Feb 14 00:39:20 lupus kernel: [ 2951.853999] Stack:
Feb 14 00:39:20 lupus kernel: [ 2951.854006] ffff880129a11b50
ffff880000000003 ffff88003c60a098 0000000000000003
Feb 14 00:39:20 lupus kernel: [ 2951.854035] ffffffffffffffff
ffffffff810e6aaa 0000000000000000 0000000602e4ac40
Feb 14 00:39:20 lupus kernel: [ 2951.854063] ffffffff8133e3f0
ffffffff810e6cee 0000000000001000 0000000000000000
Feb 14 00:39:20 lupus kernel: [ 2951.854092] Call Trace:
Feb 14 00:39:20 lupus kernel: [ 2951.854103] [<ffffffff810e6aaa>] ?
cleancache_get_key+0x4a/0x60
Feb 14 00:39:20 lupus kernel: [ 2951.854122] [<ffffffff8133e3f0>] ?
btrfs_wake_function+0x0/0x20
Feb 14 00:39:20 lupus kernel: [ 2951.854140] [<ffffffff810e6cee>] ?
__cleancache_flush_inode+0x3e/0x70
Feb 14 00:39:20 lupus kernel: [ 2951.854161] [<ffffffff810b34d2>] ?
truncate_inode_pages_range+0x42/0x440
Feb 14 00:39:20 lupus kernel: [ 2951.854182] [<ffffffff812f115e>] ?
btrfs_search_slot+0x89e/0xa00
Feb 14 00:39:20 lupus kernel: [ 2951.854201] [<ffffffff810c3a45>] ?
unmap_mapping_range+0xc5/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854220] [<ffffffff810b3930>] ?
truncate_pagecache+0x40/0x70
Feb 14 00:39:20 lupus kernel: [ 2951.854240] [<ffffffff813458b1>] ?
btrfs_truncate_free_space_cache+0x81/0xe0
Feb 14 00:39:20 lupus kernel: [ 2951.854261] [<ffffffff812fce15>] ?
btrfs_write_dirty_block_groups+0x245/0x500
Feb 14 00:39:20 lupus kernel: [ 2951.854283] [<ffffffff812fcb6a>] ?
btrfs_run_delayed_refs+0x1ba/0x220
Feb 14 00:39:20 lupus kernel: [ 2951.854304] [<ffffffff8130afff>] ?
commit_cowonly_roots+0xff/0x1d0
Feb 14 00:39:20 lupus kernel: [ 2951.854323] [<ffffffff8130c583>] ?
btrfs_commit_transaction+0x363/0x760
Feb 14 00:39:20 lupus kernel: [ 2951.854344] [<ffffffff81067ea0>] ?
autoremove_wake_function+0x0/0x30
Feb 14 00:39:20 lupus kernel: [ 2951.854364] [<ffffffff81305bc3>] ?
transaction_kthread+0x283/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854383] [<ffffffff81305940>] ?
transaction_kthread+0x0/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854401] [<ffffffff81305940>] ?
transaction_kthread+0x0/0x2a0
Feb 14 00:39:20 lupus kernel: [ 2951.854420] [<ffffffff81067a16>] ?
kthread+0x96/0xa0
Feb 14 00:39:20 lupus kernel: [ 2951.854437] [<ffffffff81003514>] ?
kernel_thread_helper+0x4/0x10
Feb 14 00:39:20 lupus kernel: [ 2951.854455] [<ffffffff81067980>] ?
kthread+0x0/0xa0
Feb 14 00:39:20 lupus kernel: [ 2951.854471] [<ffffffff81003510>] ?
kernel_thread_helper+0x0/0x10
Feb 14 00:39:20 lupus kernel: [ 2951.854488] Code: 55 b8 ff 00 00 00
53 48 89 fb 48 83 ec 18 48 8b 6f 10 8b 3a 83 ff 04 0f 86 d5 00 00 00
85 c9 0f 95 c1 83 ff 07 0f 86 d5 00 00 00 <48> 8b 45 50 bf 05 00 00 00
48 89 06 84 c9 48 8b 85 68 fe ff ff
Feb 14 00:39:20 lupus kernel: [ 2951.854742] RIP [<ffffffff8133ef1b>]
btrfs_encode_fh+0x2b/0x120
Feb 14 00:39:20 lupus kernel: [ 2951.854762] RSP <ffff880129a11b00>
Feb 14 00:39:20 lupus kernel: [ 2951.854773] CR2: 0000000001400050
Feb 14 00:39:20 lupus kernel: [ 2951.860906] ---[ end trace
f831c5ceeaa49287 ]---
in my case I had compress-force with lzo and disk_cache enabled
another user of the kernel I'm currently running has had the same
problem with zcache
(http://forums.gentoo.org/viewtopic-p-6571799.html#6571799)
(looks like in his case compression and any other fancy additional
features weren't enabled)
changes made by this kernel or patchset to btrfs are from
* io-less dirty throttling patchset (44 patches)
* zcache V2 ("[PATCH] staging: zcache: fix memory leak" should be
applied in both cases)
* PATCH] fix (latent?) memory corruption in btrfs_encode_fh()
* btrfs-unstable changes to state of
3a90983dbdcb2f4f48c0d771d8e5b4d88f27fae6 (so practically equals btrfs
from 2.6.38-rc4+)
I haven't tried downgrading to vanilla 2.6.37 with zcache only, yet,
but kind of upgraded btrfs to the latest state of the btrfs-unstable
repository (http://git.eu.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=summary)
namely 3a90983dbdcb2f4f48c0d771d8e5b4d88f27fae6
this also didn't help and seemed to produce the same error-message
so to summarize:
1) error message appearing with all 4 patchsets applied changing
btrfs-code and compress-force=lzo and disk_cache enabled
2) error message appearing with default mount-options and btrfs from
2.6.37 and changes for zcache & io-less dirty throttling patchset
applied (first 2 patch(sets)) from list)
in my case I tried to extract / play back a 1.7 GiB tarball of my
portage-directory (lots of small files and some tar.bzip2 archives)
via pbzip2 or 7z when the error happened and the message was shown
Due to KMS sound (webradio streaming) was still running but I couldn't
continue work (X switching to kernel output) so I did the magic sysrq
combo (reisub)
Does that BUG message ring a bell for anyone ?
(if I should leave out anyone from the CC in the next emails or
future, please holler - I don't want to spam your inboxes)
Thanks
Matt
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 4/4] drm/radeon/kms: evergreen/ni big endian fixes (v2)
From: Alex Deucher @ 2011-02-14 0:06 UTC (permalink / raw)
To: airlied, dri-devel; +Cc: ccano
In-Reply-To: <1297471539-1439-4-git-send-email-alexdeucher@gmail.com>
Based on 6xx/7xx endian fixes from Cédric Cano.
v2: fix typo in shader
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
---
drivers/gpu/drm/radeon/evergreen.c | 22 +++++++++++++++++-----
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 19 ++++++++++++++-----
drivers/gpu/drm/radeon/evergreen_blit_shaders.c | 8 ++++++++
drivers/gpu/drm/radeon/evergreend.h | 1 +
4 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
index 993a7cd..6fff248 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1192,7 +1192,11 @@ void evergreen_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib)
radeon_ring_write(rdev, 1);
/* FIXME: implement */
radeon_ring_write(rdev, PACKET3(PACKET3_INDIRECT_BUFFER, 2));
- radeon_ring_write(rdev, ib->gpu_addr & 0xFFFFFFFC);
+ radeon_ring_write(rdev,
+#ifdef __BIG_ENDIAN
+ (2 << 0) |
+#endif
+ (ib->gpu_addr & 0xFFFFFFFC));
radeon_ring_write(rdev, upper_32_bits(ib->gpu_addr) & 0xFF);
radeon_ring_write(rdev, ib->length_dw);
}
@@ -1207,7 +1211,11 @@ static int evergreen_cp_load_microcode(struct radeon_device *rdev)
return -EINVAL;
r700_cp_stop(rdev);
- WREG32(CP_RB_CNTL, RB_NO_UPDATE | (15 << 8) | (3 << 0));
+ WREG32(CP_RB_CNTL,
+#ifdef __BIG_ENDIAN
+ BUF_SWAP_32BIT |
+#endif
+ RB_NO_UPDATE | RB_BLKSZ(15) | RB_BUFSZ(3));
fw_data = (const __be32 *)rdev->pfp_fw->data;
WREG32(CP_PFP_UCODE_ADDR, 0);
@@ -1326,7 +1334,11 @@ int evergreen_cp_resume(struct radeon_device *rdev)
WREG32(CP_RB_WPTR, 0);
/* set the wb address wether it's enabled or not */
- WREG32(CP_RB_RPTR_ADDR, (rdev->wb.gpu_addr + RADEON_WB_CP_RPTR_OFFSET) & 0xFFFFFFFC);
+ WREG32(CP_RB_RPTR_ADDR,
+#ifdef __BIG_ENDIAN
+ RB_RPTR_SWAP(2) |
+#endif
+ ((rdev->wb.gpu_addr + RADEON_WB_CP_RPTR_OFFSET) & 0xFFFFFFFC));
WREG32(CP_RB_RPTR_ADDR_HI, upper_32_bits(rdev->wb.gpu_addr + RADEON_WB_CP_RPTR_OFFSET) & 0xFF);
WREG32(SCRATCH_ADDR, ((rdev->wb.gpu_addr + RADEON_WB_SCRATCH_OFFSET) >> 8) & 0xFFFFFFFF);
@@ -2627,8 +2639,8 @@ restart_ih:
while (rptr != wptr) {
/* wptr/rptr are in bytes! */
ring_index = rptr / 4;
- src_id = rdev->ih.ring[ring_index] & 0xff;
- src_data = rdev->ih.ring[ring_index + 1] & 0xfffffff;
+ src_id = le32_to_cpu(rdev->ih.ring[ring_index]) & 0xff;
+ src_data = le32_to_cpu(rdev->ih.ring[ring_index + 1]) & 0xfffffff;
switch (src_id) {
case 1: /* D1 vblank/vline */
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index b3f99f4..2adfb03 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -133,6 +133,9 @@ set_vtx_resource(struct radeon_device *rdev, u64 gpu_addr)
/* high addr, stride */
sq_vtx_constant_word2 = ((upper_32_bits(gpu_addr) & 0xff) | (16 << 8));
+#ifdef __BIG_ENDIAN
+ sq_vtx_constant_word2 |= (2 << 30);
+#endif
/* xyzw swizzles */
sq_vtx_constant_word3 = (0 << 3) | (1 << 6) | (2 << 9) | (3 << 12);
@@ -221,7 +224,11 @@ draw_auto(struct radeon_device *rdev)
radeon_ring_write(rdev, DI_PT_RECTLIST);
radeon_ring_write(rdev, PACKET3(PACKET3_INDEX_TYPE, 0));
- radeon_ring_write(rdev, DI_INDEX_SIZE_16_BIT);
+ radeon_ring_write(rdev,
+#ifdef __BIG_ENDIAN
+ (2 << 2) |
+#endif
+ DI_INDEX_SIZE_16_BIT);
radeon_ring_write(rdev, PACKET3(PACKET3_NUM_INSTANCES, 0));
radeon_ring_write(rdev, 1);
@@ -541,7 +548,7 @@ static inline uint32_t i2f(uint32_t input)
int evergreen_blit_init(struct radeon_device *rdev)
{
u32 obj_size;
- int r, dwords;
+ int i, r, dwords;
void *ptr;
u32 packet2s[16];
int num_packet2s = 0;
@@ -557,7 +564,7 @@ int evergreen_blit_init(struct radeon_device *rdev)
dwords = rdev->r600_blit.state_len;
while (dwords & 0xf) {
- packet2s[num_packet2s++] = PACKET2(0);
+ packet2s[num_packet2s++] = cpu_to_le32(PACKET2(0));
dwords++;
}
@@ -598,8 +605,10 @@ int evergreen_blit_init(struct radeon_device *rdev)
if (num_packet2s)
memcpy_toio(ptr + rdev->r600_blit.state_offset + (rdev->r600_blit.state_len * 4),
packet2s, num_packet2s * 4);
- memcpy(ptr + rdev->r600_blit.vs_offset, evergreen_vs, evergreen_vs_size * 4);
- memcpy(ptr + rdev->r600_blit.ps_offset, evergreen_ps, evergreen_ps_size * 4);
+ for (i = 0; i < evergreen_vs_size; i++)
+ *(u32 *)((unsigned long)ptr + rdev->r600_blit.vs_offset + i * 4) = cpu_to_le32(evergreen_vs[i]);
+ for (i = 0; i < evergreen_ps_size; i++)
+ *(u32 *)((unsigned long)ptr + rdev->r600_blit.ps_offset + i * 4) = cpu_to_le32(evergreen_ps[i]);
radeon_bo_kunmap(rdev->r600_blit.shader_obj);
radeon_bo_unreserve(rdev->r600_blit.shader_obj);
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_shaders.c b/drivers/gpu/drm/radeon/evergreen_blit_shaders.c
index ef1d28c..3a10399 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_shaders.c
@@ -311,11 +311,19 @@ const u32 evergreen_vs[] =
0x00000000,
0x3c000000,
0x67961001,
+#ifdef __BIG_ENDIAN
+ 0x000a0000,
+#else
0x00080000,
+#endif
0x00000000,
0x1c000000,
0x67961000,
+#ifdef __BIG_ENDIAN
+ 0x00020008,
+#else
0x00000008,
+#endif
0x00000000,
};
diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h
index 21e839b..9aaa3f0 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -98,6 +98,7 @@
#define BUF_SWAP_32BIT (2 << 16)
#define CP_RB_RPTR 0x8700
#define CP_RB_RPTR_ADDR 0xC10C
+#define RB_RPTR_SWAP(x) ((x) << 0)
#define CP_RB_RPTR_ADDR_HI 0xC110
#define CP_RB_RPTR_WR 0xC108
#define CP_RB_WPTR 0xC114
--
1.7.1.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* 祝乐事连连全家福!s3w8OPq6B
From: 朱美华 @ 2011-02-14 0:04 UTC (permalink / raw)
To: spi-devel-general
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
┌─┬─┬─┬─┬─┬─┬─┐
│。┆取┆败┆中┆ ┆资┆Ｄ│
│ ┆风┆揭┆国┆ ┆料┆Ｋ│
│ ┆险┆示┆诸┆ ┆见┆Ｗ│
│ ┆管┆了┆多┆ ┆附┆Ｊ│
│ ┆ｖ┆内┆企┆ ┆ｚ┆Ｙ│
│ ┆理┆部┆业┆ ┆件┆Ｄ│
│ ┆的┆控┆的┆ ┆ ┆Ｕ│
│ ┆必┆制┆兴┆ ┆ ┆Ｊ│
│ ┆要┆与┆衰┆ ┆ ┆学│
│ ┆性┆采┆成┆ ┆ ┆习│
└─┴─┴─┴─┴─┴─┴─┘
[-- Attachment #2: Type: text/plain, Size: 387 bytes --]
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
[-- Attachment #3: Type: text/plain, Size: 210 bytes --]
_______________________________________________
spi-devel-general mailing list
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply
* Re: [BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
From: Justin Mattock @ 2011-02-14 0:02 UTC (permalink / raw)
To: Alex Deucher; +Cc: dri-devel, linux-kernel@vger.kernel.org, airlied
In-Reply-To: <AANLkTikrZZ6i6di-c0zBav0zT5OOvmOXvX7SAXTW18z+@mail.gmail.com>
>
> The attached patch is what I'm proposing to go upstream. Please test
> and let me know if it works ok for you.
>
> Alex
>
o.k.!! I have 6 revisions to test on another issue, then I can throw
this in and let you know..
Justin P. Mattock
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO
From: David Gibson @ 2011-02-13 23:30 UTC (permalink / raw)
To: Anthony Liguori
Cc: Blue Swirl, Alexander Graf, Paul Mackerras,
qemu-devel@nongnu.org List, anton
In-Reply-To: <4D57F3E6.10504@codemonkey.ws>
On Sun, Feb 13, 2011 at 09:08:22AM -0600, Anthony Liguori wrote:
> On 02/13/2011 05:12 AM, David Gibson wrote:
> >On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
> >>On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
[snip]
> In KVM for x86, instead of using a secondary interface (like
> vmmcall/vmcall), we do all of our paravirtualization using native
> hardware interfaces that we can trap (PIO/MMIO).
>
> IIUC, on Power, trapping MMIO is not possible due to the MMU mode
> that is currently used (PFs are delivered directly to the guest).
>
> So it's not really possible to switch from using hypercalls to using MMIO.
That's correct.
> What I would suggest is modelling hypercalls as another I/O address
> space for the processor. So instead of having a function pointer in
> the CPUState, introduce a:
>
> typedef void (HypercallFunc)(CPUState *env, void *opaque);
>
> /* register a hypercall handler */
> void register_hypercall(target_ulong index, HypercallFunc *handler,
> void *opaque);
> void unregister_hypercall(target_ulong index);
>
> /* dispatch a hypercall */
> void cpu_hypercall(CPUState *env, target_ulong index);
Well, I can certainly implement dynamic registration - in fact I've
done that, I just need to fold it into the earlier part of the patch
series.
But the only "address" we have for this hypercall address space is the
hypercall number, and it's not architected where that will be
supplied. So we'd still need a per-platform hook to extract the
index from the CPUState.
> This interface could also be used to implement hypercall based
> interfaces on s390 and x86.
>
> The arguments will have to be extracted from the CPU state but I
> don't think we'll really ever have common hypercall implementations
> anyway so that's not a huge problem.
>
> >>on real HW?
> >The interface already exists on real HW. It's described in the PAPR
> >document we keep mentioning.
>
> Another thing to note is that the hypercall based I/O devices the
> interfaces that the current Power hypervisor uses so implementing
> this interface is necessary to support existing guests.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO
From: David Gibson @ 2011-02-13 23:33 UTC (permalink / raw)
To: Blue Swirl
Cc: Alexander Graf, Paul Mackerras, qemu-devel@nongnu.org List, anton
In-Reply-To: <AANLkTik8gfBDrMwWmVTshopHKiuO6CQQge605dxDJwvt@mail.gmail.com>
On Sun, Feb 13, 2011 at 08:29:05PM +0200, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > On 02/13/2011 05:12 AM, David Gibson wrote:
[snip]
> > The arguments will have to be extracted from the CPU state but I don't think
> > we'll really ever have common hypercall implementations anyway so that's not
> > a huge problem.
>
> Nice idea. Then the part handling CPUState probably should belong to
> target-ppc/ rather than hw/.
Doesn't work. Different hypervisors may have arguments - even the
hcall number itself - arranged differently in the registers. My
earlier drafts had this in target-ppc/; I moved it to hw/ for a
reason.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 2/2] drm/radeon/kms: check AA resolve registers on r300
From: Marek Olšák @ 2011-02-14 0:01 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <1297641670-5839-1-git-send-email-maraeo@gmail.com>
This is an important security fix because we allowed arbitrary values
to be passed to AARESOLVE_OFFSET. This also puts the right buffer address
in the register.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
---
drivers/gpu/drm/radeon/r100.c | 25 +++++++++++++++++++++++++
drivers/gpu/drm/radeon/r100_track.h | 4 ++++
drivers/gpu/drm/radeon/r300.c | 21 +++++++++++++++++++++
drivers/gpu/drm/radeon/r300_reg.h | 2 ++
drivers/gpu/drm/radeon/reg_srcs/r300 | 3 ---
drivers/gpu/drm/radeon/reg_srcs/r420 | 3 ---
drivers/gpu/drm/radeon/reg_srcs/rs600 | 3 ---
drivers/gpu/drm/radeon/reg_srcs/rv515 | 3 ---
8 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 5f15820..c5c4459 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3358,6 +3358,27 @@ int r100_cs_track_check(struct radeon_device *rdev, struct r100_cs_track *track)
return -EINVAL;
}
}
+
+ if (track->aa_dirty && track->aaresolve) {
+ if (track->aa.robj == NULL) {
+ DRM_ERROR("[drm] No buffer for AA resolve buffer %d !\n", i);
+ return -EINVAL;
+ }
+ /* I believe the format comes from colorbuffer0. */
+ size = track->aa.pitch * track->cb[0].cpp * track->maxy;
+ size += track->aa.offset;
+ if (size > radeon_bo_size(track->aa.robj)) {
+ DRM_ERROR("[drm] Buffer too small for AA resolve buffer %d "
+ "(need %lu have %lu) !\n", i, size,
+ radeon_bo_size(track->aa.robj));
+ DRM_ERROR("[drm] AA resolve buffer %d (%u %u %u %u)\n",
+ i, track->aa.pitch, track->cb[0].cpp,
+ track->aa.offset, track->maxy);
+ return -EINVAL;
+ }
+ }
+ track->aa_dirty = false;
+
prim_walk = (track->vap_vf_cntl >> 4) & 0x3;
if (track->vap_vf_cntl & (1 << 14)) {
nverts = track->vap_alt_nverts;
@@ -3424,6 +3445,8 @@ void r100_cs_track_clear(struct radeon_device *rdev, struct r100_cs_track *track
{
unsigned i, face;
+ track->aa_dirty = true;
+
if (rdev->family < CHIP_R300) {
track->num_cb = 1;
if (rdev->family <= CHIP_RS200)
@@ -3437,6 +3460,8 @@ void r100_cs_track_clear(struct radeon_device *rdev, struct r100_cs_track *track
track->num_texture = 16;
track->maxy = 4096;
track->separate_cube = 0;
+ track->aaresolve = true;
+ track->aa.robj = NULL;
}
for (i = 0; i < track->num_cb; i++) {
diff --git a/drivers/gpu/drm/radeon/r100_track.h b/drivers/gpu/drm/radeon/r100_track.h
index af65600..6b31ed3 100644
--- a/drivers/gpu/drm/radeon/r100_track.h
+++ b/drivers/gpu/drm/radeon/r100_track.h
@@ -73,11 +73,15 @@ struct r100_cs_track {
struct r100_cs_track_array arrays[11];
struct r100_cs_track_cb cb[R300_MAX_CB];
struct r100_cs_track_cb zb;
+ struct r100_cs_track_cb aa;
struct r100_cs_track_texture textures[R300_TRACK_MAX_TEXTURE];
bool z_enabled;
bool separate_cube;
bool zb_cb_clear;
bool blend_read_enable;
+ bool aaresolve;
+
+ bool aa_dirty;
};
int r100_cs_track_check(struct radeon_device *rdev, struct r100_cs_track *track);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 4fee92b..1b89b16 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1086,6 +1086,27 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
/* RB3D_BLENDCNTL */
track->blend_read_enable = !!(idx_value & (1 << 2));
break;
+ case R300_RB3D_AARESOLVE_OFFSET:
+ r = r100_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ DRM_ERROR("No reloc for ib[%d]=0x%04X\n",
+ idx, reg);
+ r100_cs_dump_packet(p, pkt);
+ return r;
+ }
+ track->aa.robj = reloc->robj;
+ track->aa.offset = idx_value;
+ track->aa_dirty = true;
+ ib[idx] = idx_value + ((u32)reloc->lobj.gpu_offset);
+ break;
+ case R300_RB3D_AARESOLVE_PITCH:
+ track->aa.pitch = idx_value & 0x3FFE;
+ track->aa_dirty = true;
+ break;
+ case R300_RB3D_AARESOLVE_CTL:
+ track->aaresolve = idx_value & 0x1;
+ track->aa_dirty = true;
+ break;
case 0x4f30: /* ZB_MASK_OFFSET */
case 0x4f34: /* ZB_ZMASK_PITCH */
case 0x4f44: /* ZB_HIZ_OFFSET */
diff --git a/drivers/gpu/drm/radeon/r300_reg.h b/drivers/gpu/drm/radeon/r300_reg.h
index 1a0d536..f0bce39 100644
--- a/drivers/gpu/drm/radeon/r300_reg.h
+++ b/drivers/gpu/drm/radeon/r300_reg.h
@@ -1371,6 +1371,8 @@
#define R300_RB3D_COLORPITCH2 0x4E40 /* GUESS */
#define R300_RB3D_COLORPITCH3 0x4E44 /* GUESS */
+#define R300_RB3D_AARESOLVE_OFFSET 0x4E80
+#define R300_RB3D_AARESOLVE_PITCH 0x4E84
#define R300_RB3D_AARESOLVE_CTL 0x4E88
/* gap */
diff --git a/drivers/gpu/drm/radeon/reg_srcs/r300 b/drivers/gpu/drm/radeon/reg_srcs/r300
index 13a94e2..e8a1786 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/r300
+++ b/drivers/gpu/drm/radeon/reg_srcs/r300
@@ -704,9 +704,6 @@ r300 0x4f60
0x4E74 RB3D_CMASK_WRINDEX
0x4E78 RB3D_CMASK_DWORD
0x4E7C RB3D_CMASK_RDINDEX
-0x4E80 RB3D_AARESOLVE_OFFSET
-0x4E84 RB3D_AARESOLVE_PITCH
-0x4E88 RB3D_AARESOLVE_CTL
0x4EA0 RB3D_DISCARD_SRC_PIXEL_LTE_THRESHOLD
0x4EA4 RB3D_DISCARD_SRC_PIXEL_GTE_THRESHOLD
0x4F04 ZB_ZSTENCILCNTL
diff --git a/drivers/gpu/drm/radeon/reg_srcs/r420 b/drivers/gpu/drm/radeon/reg_srcs/r420
index 5c95cf8..722074e 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/r420
+++ b/drivers/gpu/drm/radeon/reg_srcs/r420
@@ -770,9 +770,6 @@ r420 0x4f60
0x4E74 RB3D_CMASK_WRINDEX
0x4E78 RB3D_CMASK_DWORD
0x4E7C RB3D_CMASK_RDINDEX
-0x4E80 RB3D_AARESOLVE_OFFSET
-0x4E84 RB3D_AARESOLVE_PITCH
-0x4E88 RB3D_AARESOLVE_CTL
0x4EA0 RB3D_DISCARD_SRC_PIXEL_LTE_THRESHOLD
0x4EA4 RB3D_DISCARD_SRC_PIXEL_GTE_THRESHOLD
0x4F04 ZB_ZSTENCILCNTL
diff --git a/drivers/gpu/drm/radeon/reg_srcs/rs600 b/drivers/gpu/drm/radeon/reg_srcs/rs600
index 263109c..d9f6286 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/rs600
+++ b/drivers/gpu/drm/radeon/reg_srcs/rs600
@@ -770,9 +770,6 @@ rs600 0x6d40
0x4E74 RB3D_CMASK_WRINDEX
0x4E78 RB3D_CMASK_DWORD
0x4E7C RB3D_CMASK_RDINDEX
-0x4E80 RB3D_AARESOLVE_OFFSET
-0x4E84 RB3D_AARESOLVE_PITCH
-0x4E88 RB3D_AARESOLVE_CTL
0x4EA0 RB3D_DISCARD_SRC_PIXEL_LTE_THRESHOLD
0x4EA4 RB3D_DISCARD_SRC_PIXEL_GTE_THRESHOLD
0x4F04 ZB_ZSTENCILCNTL
diff --git a/drivers/gpu/drm/radeon/reg_srcs/rv515 b/drivers/gpu/drm/radeon/reg_srcs/rv515
index eeed003..911a8fb 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/rv515
+++ b/drivers/gpu/drm/radeon/reg_srcs/rv515
@@ -481,9 +481,6 @@ rv515 0x6d40
0x4E74 RB3D_CMASK_WRINDEX
0x4E78 RB3D_CMASK_DWORD
0x4E7C RB3D_CMASK_RDINDEX
-0x4E80 RB3D_AARESOLVE_OFFSET
-0x4E84 RB3D_AARESOLVE_PITCH
-0x4E88 RB3D_AARESOLVE_CTL
0x4EA0 RB3D_DISCARD_SRC_PIXEL_LTE_THRESHOLD
0x4EA4 RB3D_DISCARD_SRC_PIXEL_GTE_THRESHOLD
0x4EF8 RB3D_CONSTANT_COLOR_AR
--
1.7.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 1/2] drm/radeon/kms: fix tracking of BLENDCNTL, COLOR_CHANNEL_MASK, and GB_Z on r300
From: Marek Olšák @ 2011-02-14 0:01 UTC (permalink / raw)
To: dri-devel
Also move ZB_DEPTHCLEARVALUE to the list of safe regs.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
---
drivers/gpu/drm/radeon/r300.c | 3 +--
drivers/gpu/drm/radeon/reg_srcs/r300 | 3 +--
drivers/gpu/drm/radeon/reg_srcs/r420 | 4 +---
drivers/gpu/drm/radeon/reg_srcs/rs600 | 3 +--
drivers/gpu/drm/radeon/reg_srcs/rv515 | 4 +---
5 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 55fe5ba..4fee92b 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -863,6 +863,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
track->zb.pitch = idx_value & 0x3FFC;
break;
case 0x4104:
+ /* TX_ENABLE */
for (i = 0; i < 16; i++) {
bool enabled;
@@ -1085,8 +1086,6 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
/* RB3D_BLENDCNTL */
track->blend_read_enable = !!(idx_value & (1 << 2));
break;
- case 0x4f28: /* ZB_DEPTHCLEARVALUE */
- break;
case 0x4f30: /* ZB_MASK_OFFSET */
case 0x4f34: /* ZB_ZMASK_PITCH */
case 0x4f44: /* ZB_HIZ_OFFSET */
diff --git a/drivers/gpu/drm/radeon/reg_srcs/r300 b/drivers/gpu/drm/radeon/reg_srcs/r300
index b506ec1..13a94e2 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/r300
+++ b/drivers/gpu/drm/radeon/reg_srcs/r300
@@ -683,9 +683,7 @@ r300 0x4f60
0x4DF4 US_ALU_CONST_G_31
0x4DF8 US_ALU_CONST_B_31
0x4DFC US_ALU_CONST_A_31
-0x4E04 RB3D_BLENDCNTL_R3
0x4E08 RB3D_ABLENDCNTL_R3
-0x4E0C RB3D_COLOR_CHANNEL_MASK
0x4E10 RB3D_CONSTANT_COLOR
0x4E14 RB3D_COLOR_CLEAR_VALUE
0x4E18 RB3D_ROPCNTL_R3
@@ -715,4 +713,5 @@ r300 0x4f60
0x4F08 ZB_STENCILREFMASK
0x4F14 ZB_ZTOP
0x4F18 ZB_ZCACHE_CTLSTAT
+0x4F28 ZB_DEPTHCLEARVALUE
0x4F58 ZB_ZPASS_DATA
diff --git a/drivers/gpu/drm/radeon/reg_srcs/r420 b/drivers/gpu/drm/radeon/reg_srcs/r420
index 8c1214c..5c95cf8 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/r420
+++ b/drivers/gpu/drm/radeon/reg_srcs/r420
@@ -130,7 +130,6 @@ r420 0x4f60
0x401C GB_SELECT
0x4020 GB_AA_CONFIG
0x4024 GB_FIFO_SIZE
-0x4028 GB_Z_PEQ_CONFIG
0x4100 TX_INVALTAGS
0x4200 GA_POINT_S0
0x4204 GA_POINT_T0
@@ -750,9 +749,7 @@ r420 0x4f60
0x4DF4 US_ALU_CONST_G_31
0x4DF8 US_ALU_CONST_B_31
0x4DFC US_ALU_CONST_A_31
-0x4E04 RB3D_BLENDCNTL_R3
0x4E08 RB3D_ABLENDCNTL_R3
-0x4E0C RB3D_COLOR_CHANNEL_MASK
0x4E10 RB3D_CONSTANT_COLOR
0x4E14 RB3D_COLOR_CLEAR_VALUE
0x4E18 RB3D_ROPCNTL_R3
@@ -782,4 +779,5 @@ r420 0x4f60
0x4F08 ZB_STENCILREFMASK
0x4F14 ZB_ZTOP
0x4F18 ZB_ZCACHE_CTLSTAT
+0x4F28 ZB_DEPTHCLEARVALUE
0x4F58 ZB_ZPASS_DATA
diff --git a/drivers/gpu/drm/radeon/reg_srcs/rs600 b/drivers/gpu/drm/radeon/reg_srcs/rs600
index 0828d80..263109c 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/rs600
+++ b/drivers/gpu/drm/radeon/reg_srcs/rs600
@@ -749,9 +749,7 @@ rs600 0x6d40
0x4DF4 US_ALU_CONST_G_31
0x4DF8 US_ALU_CONST_B_31
0x4DFC US_ALU_CONST_A_31
-0x4E04 RB3D_BLENDCNTL_R3
0x4E08 RB3D_ABLENDCNTL_R3
-0x4E0C RB3D_COLOR_CHANNEL_MASK
0x4E10 RB3D_CONSTANT_COLOR
0x4E14 RB3D_COLOR_CLEAR_VALUE
0x4E18 RB3D_ROPCNTL_R3
@@ -781,4 +779,5 @@ rs600 0x6d40
0x4F08 ZB_STENCILREFMASK
0x4F14 ZB_ZTOP
0x4F18 ZB_ZCACHE_CTLSTAT
+0x4F28 ZB_DEPTHCLEARVALUE
0x4F58 ZB_ZPASS_DATA
diff --git a/drivers/gpu/drm/radeon/reg_srcs/rv515 b/drivers/gpu/drm/radeon/reg_srcs/rv515
index ef422bb..eeed003 100644
--- a/drivers/gpu/drm/radeon/reg_srcs/rv515
+++ b/drivers/gpu/drm/radeon/reg_srcs/rv515
@@ -164,7 +164,6 @@ rv515 0x6d40
0x401C GB_SELECT
0x4020 GB_AA_CONFIG
0x4024 GB_FIFO_SIZE
-0x4028 GB_Z_PEQ_CONFIG
0x4100 TX_INVALTAGS
0x4114 SU_TEX_WRAP_PS3
0x4118 PS3_ENABLE
@@ -461,9 +460,7 @@ rv515 0x6d40
0x4DF4 US_ALU_CONST_G_31
0x4DF8 US_ALU_CONST_B_31
0x4DFC US_ALU_CONST_A_31
-0x4E04 RB3D_BLENDCNTL_R3
0x4E08 RB3D_ABLENDCNTL_R3
-0x4E0C RB3D_COLOR_CHANNEL_MASK
0x4E10 RB3D_CONSTANT_COLOR
0x4E14 RB3D_COLOR_CLEAR_VALUE
0x4E18 RB3D_ROPCNTL_R3
@@ -496,4 +493,5 @@ rv515 0x6d40
0x4F14 ZB_ZTOP
0x4F18 ZB_ZCACHE_CTLSTAT
0x4F58 ZB_ZPASS_DATA
+0x4F28 ZB_DEPTHCLEARVALUE
0x4FD4 ZB_STENCILREFMASK_BF
--
1.7.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: mdadm: recovering from an aborted reshape op - to ensure at least one email gets through!
From: NeilBrown @ 2011-02-14 0:00 UTC (permalink / raw)
To: Gavin Flower; +Cc: linux-raid
In-Reply-To: <758136.48398.qm@web65107.mail.ac2.yahoo.com>
On Sun, 13 Feb 2011 15:10:36 -0800 (PST) Gavin Flower <gavinflower@yahoo.com>
wrote:
> Hi Neil,
>
> I'll send this now.
>
> My previous 2 attempts failed.
>
> I had the first bounce due to HTML, but no errors reported for my second attempt.
>
> I replied to you blog post.
>
Yes - vger.kernel.org doesn't like html.
Normal attachments should work - and you should get a bounce-message
if there is something odd.
But this and the following messages did get through.
For those on linux-raid: the background is that a reshape for a RAID6
to change chunksize was interrupted by the admin killing the mdadm
which monitors the reshape. Then after a reboot the array isn't working
properly.
When I asked for "mdadm -Evs" I should have asked for an extra 'v' - I keep
forgetting that.
However for now: what would help is:
mdadm -S /dev/md1
mdadm -E /dev/md[abcde]2
mdadm -Av /dev/md1 /dev/sd[abcde]2
dmesg | tail -50
capture all of the output and post that.
Thanks,
NeilBrown
^ permalink raw reply
* Re: [PATCH] fix uncheck memory allocations
From: Tsutomu Itoh @ 2011-02-13 23:57 UTC (permalink / raw)
To: Yoshinori Sano; +Cc: linux-btrfs
In-Reply-To: <1297509433-15183-1-git-send-email-yoshinori.sano@gmail.com>
(2011/02/12 20:17), Yoshinori Sano wrote:
> To make Btrfs code more robust, several return value checks where memory
> allocation can fail are introduced. I use BUG_ON where I don't know how
> to handle the error properly, which increases the number of using the
> notorious BUG_ON, though.
>
> Signed-off-by: Yoshinori Sano <yoshinori.sano@gmail.com>
> ---
> fs/btrfs/compression.c | 6 ++++++
> fs/btrfs/extent-tree.c | 2 ++
> fs/btrfs/file.c | 8 ++++++--
> fs/btrfs/inode.c | 5 +++++
> 4 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> index 4d2110e..f596554 100644
> --- a/fs/btrfs/compression.c
> +++ b/fs/btrfs/compression.c
> @@ -340,6 +340,8 @@ int btrfs_submit_compressed_write(struct inode *inode, u64 start,
>
> WARN_ON(start & ((u64)PAGE_CACHE_SIZE - 1));
> cb = kmalloc(compressed_bio_size(root, compressed_len), GFP_NOFS);
> + if (!cb)
> + return -ENOMEM;
> atomic_set(&cb->pending_bios, 0);
> cb->errors = 0;
> cb->inode = inode;
> @@ -354,6 +356,10 @@ int btrfs_submit_compressed_write(struct inode *inode, u64 start,
> bdev = BTRFS_I(inode)->root->fs_info->fs_devices->latest_bdev;
>
> bio = compressed_bio_alloc(bdev, first_byte, GFP_NOFS);
> + if (!bio) {
> + kfree(cb);
> + return -ENOMEM;
> + }
> bio->bi_private = cb;
> bio->bi_end_io = end_compressed_bio_write;
> atomic_inc(&cb->pending_bios);
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 565e22d..aed16f4 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -6931,6 +6931,8 @@ static noinline int get_new_locations(struct inode *reloc_inode,
> struct disk_extent *old = exts;
> max *= 2;
> exts = kzalloc(sizeof(*exts) * max, GFP_NOFS);
> + if (!exts)
> + goto out;
> memcpy(exts, old, sizeof(*exts) * nr);
> if (old != *extents)
> kfree(old);
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index b0ff34b..4895ad2 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -181,10 +181,14 @@ int btrfs_drop_extent_cache(struct inode *inode, u64 start, u64 end,
> testend = 0;
> }
> while (1) {
> - if (!split)
> + if (!split) {
> split = alloc_extent_map(GFP_NOFS);
> - if (!split2)
> + BUG_ON(!split || IS_ERR(split));
alloc_extent_map() returns only the address or NULL.
Therefore, I think that check by IS_ERR() is unnecessary.
Regards,
Itoh
> + }
> + if (!split2) {
> split2 = alloc_extent_map(GFP_NOFS);
> + BUG_ON(!split2 || IS_ERR(split2));
> + }
>
> write_lock(&em_tree->lock);
> em = lookup_extent_mapping(em_tree, start, len);
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index c9bc0af..40bbe00 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -287,6 +287,7 @@ static noinline int add_async_extent(struct async_cow *cow,
> struct async_extent *async_extent;
>
> async_extent = kmalloc(sizeof(*async_extent), GFP_NOFS);
> + BUG_ON(!async_extent);
> async_extent->start = start;
> async_extent->ram_size = ram_size;
> async_extent->compressed_size = compressed_size;
> @@ -384,6 +385,7 @@ again:
> (BTRFS_I(inode)->force_compress))) {
> WARN_ON(pages);
> pages = kzalloc(sizeof(struct page *) * nr_pages, GFP_NOFS);
> + BUG_ON(!pages);
>
> if (BTRFS_I(inode)->force_compress)
> compress_type = BTRFS_I(inode)->force_compress;
> @@ -644,6 +646,7 @@ retry:
> async_extent->ram_size - 1, 0);
>
> em = alloc_extent_map(GFP_NOFS);
> + BUG_ON(!em || IS_ERR(em));
> em->start = async_extent->start;
> em->len = async_extent->ram_size;
> em->orig_start = em->start;
> @@ -820,6 +823,7 @@ static noinline int cow_file_range(struct inode *inode,
> BUG_ON(ret);
>
> em = alloc_extent_map(GFP_NOFS);
> + BUG_ON(!em || IS_ERR(em));
> em->start = start;
> em->orig_start = em->start;
> ram_size = ins.offset;
> @@ -1169,6 +1173,7 @@ out_check:
> struct extent_map_tree *em_tree;
> em_tree = &BTRFS_I(inode)->extent_tree;
> em = alloc_extent_map(GFP_NOFS);
> + BUG_ON(!em || IS_ERR(em));
> em->start = cur_offset;
> em->orig_start = em->start;
> em->len = num_bytes;
^ permalink raw reply
* mdadm: recovering from an aborted reshape op: selected log entries
From: Gavin Flower @ 2011-02-13 23:55 UTC (permalink / raw)
To: linux-raid
This is the /var/log/messages from shortly after coming up after hibernation, note that the last entries are Friday - as since then the filing system has been read only.
I have filtered out entries associated with:
named
dhcp
NetworkManager
ntpd
Feb 11 04:36:31 saturn kernel: [112405.427525] ata5.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
Feb 11 04:36:31 saturn kernel: [112405.427529] ata5.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out
Feb 11 04:36:31 saturn kernel: [112405.427532] ata5.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Feb 11 04:36:31 saturn kernel: [112405.427857] ata6.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
Feb 11 04:36:31 saturn kernel: [112405.427860] ata6.00: ACPI cmd ef/03:46:00:00:00:a0 (SET FEATURES) filtered out
Feb 11 04:36:31 saturn kernel: [112405.427862] ata6.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Feb 11 04:36:31 saturn kernel: [112405.433452] ata5.00: configured for UDMA/33
Feb 11 04:36:31 saturn kernel: [112405.461471] HDA Intel 0000:01:05.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
Feb 11 04:36:31 saturn kernel: [112405.461490] ATL1E 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Feb 11 04:36:31 saturn kernel: [112405.502503] ata6.00: configured for UDMA/100
Feb 11 04:36:31 saturn kernel: [112405.512030] ata4: softreset failed (device not ready)
Feb 11 04:36:31 saturn kernel: [112405.512033] ata1: softreset failed (device not ready)
Feb 11 04:36:31 saturn kernel: [112405.512036] ata4: applying SB600 PMP SRST workaround and retrying
Feb 11 04:36:31 saturn kernel: [112405.512038] ata1: applying SB600 PMP SRST workaround and retrying
Feb 11 04:36:31 saturn kernel: [112405.512057] ata3: softreset failed (device not ready)
Feb 11 04:36:31 saturn kernel: [112405.512060] ata3: applying SB600 PMP SRST workaround and retrying
Feb 11 04:36:31 saturn kernel: [112405.512062] ata2: softreset failed (device not ready)
Feb 11 04:36:31 saturn kernel: [112405.512065] ata2: applying SB600 PMP SRST workaround and retrying
Feb 11 04:36:31 saturn kernel: [112405.522058] firewire_core: skipped bus generations, destroying all nodes
Feb 11 04:36:31 saturn kernel: [112405.526548] serial 00:09: activated
Feb 11 04:36:31 saturn kernel: [112405.667039] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 11 04:36:31 saturn kernel: [112405.667056] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 11 04:36:31 saturn kernel: [112405.667069] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 11 04:36:31 saturn kernel: [112405.667085] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 11 04:36:31 saturn kernel: [112405.669351] ata3.00: configured for UDMA/133
Feb 11 04:36:31 saturn kernel: [112405.733598] ata2.00: configured for UDMA/133
Feb 11 04:36:31 saturn kernel: [112405.733660] ata1.00: configured for UDMA/133
Feb 11 04:36:31 saturn kernel: [112405.733706] ata4.00: configured for UDMA/133
Feb 11 04:36:31 saturn kernel: [112406.023036] firewire_core: rediscovered device fw0
Feb 11 04:36:31 saturn kernel: [112407.090029] usb 1-4: reset high speed USB device using ehci_hcd and address 5
Feb 11 04:36:31 saturn kernel: [112407.341394] snd-usb-audio 1-4:1.2: no reset_resume for driver snd-usb-audio?
Feb 11 04:36:31 saturn kernel: [112407.341397] snd-usb-audio 1-4:1.3: no reset_resume for driver snd-usb-audio?
Feb 11 04:36:31 saturn kernel: [112407.614035] usb 3-1: reset low speed USB device using ohci_hcd and address 2
Feb 11 04:36:31 saturn kernel: [112407.915468] sd 0:0:0:0: [sda] Starting disk
Feb 11 04:36:31 saturn kernel: [112407.924908] sd 1:0:0:0: [sdb] Starting disk
Feb 11 04:36:31 saturn kernel: [112407.935249] sd 2:0:0:0: [sdc] Starting disk
Feb 11 04:36:31 saturn kernel: [112407.949675] sd 3:0:0:0: [sdd] Starting disk
Feb 11 04:36:31 saturn kernel: [112408.236035] usb 3-2: reset low speed USB device using ohci_hcd and address 3
Feb 11 04:36:31 saturn kernel: [112408.533547] sd 5:0:0:0: [sde] Starting disk
Feb 11 04:36:31 saturn kernel: [112408.666031] usb 3-3: reset full speed USB device using ohci_hcd and address 4
Feb 11 04:36:31 saturn kernel: [112408.812474] usblp 3-3:1.0: no reset_resume for driver usblp?
Feb 11 04:36:31 saturn kernel: [112408.812588] usblp0: removed
Feb 11 04:36:31 saturn kernel: [112408.812614] PM: restore of devices complete after 3760.064 msecs
Feb 11 04:36:31 saturn kernel: [112408.818602] usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0028
Feb 11 04:36:31 saturn kernel: [112409.146196] Restarting tasks ... done.
Feb 11 04:36:41 saturn rtkit-daemon[3408]: Recovering from system lockup, not allowing further RT threads.
Feb 11 04:36:41 saturn rtkit-daemon[3408]: Recovering from system lockup, not allowing further RT threads.
Feb 11 04:36:44 saturn kernel: [112424.567629] ADDRCONF(NETDEV_UP): eth0: link is not ready
Feb 11 04:36:44 saturn kernel: [112424.571848] r8169 0000:04:05.0: eth1: link up
Feb 11 04:36:44 saturn kernel: [112424.571882] r8169 0000:04:05.0: eth1: link up
Feb 11 04:36:44 saturn dnsmasq[3143]: no servers found in /etc/resolv.conf, will retry
Feb 11 04:36:44 saturn avahi-daemon[1658]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.204.
Feb 11 04:36:44 saturn avahi-daemon[1658]: New relevant interface eth1.IPv4 for mDNS.
Feb 11 04:36:44 saturn avahi-daemon[1658]: Registering new address record for 192.168.1.204 on eth1.IPv4.
Feb 11 04:36:46 saturn avahi-daemon[1658]: Registering new address record for fe80::208:54ff:fe55:e1e7 on eth1.*.
Feb 11 04:36:46 saturn kernel: [112426.092986] ATL1E 0000:02:00.0: eth0: NIC Link is Up <100 Mbps Full Duplex>
Feb 11 04:36:46 saturn kernel: [112426.097195] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Feb 11 04:36:46 saturn dnsmasq[3143]: reading /etc/resolv.conf
Feb 11 04:36:46 saturn dnsmasq[3143]: using nameserver 192.168.1.204#53
Feb 11 04:36:46 saturn avahi-daemon[1658]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.1.1.3.
Feb 11 04:36:46 saturn avahi-daemon[1658]: New relevant interface eth0.IPv4 for mDNS.
Feb 11 04:36:46 saturn avahi-daemon[1658]: Registering new address record for 10.1.1.3 on eth0.IPv4.
Feb 11 04:36:46 saturn kernel: [112426.207274] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=105 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=85
Feb 11 04:36:46 saturn kernel: [112426.357331] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=461 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=441
Feb 11 04:36:46 saturn kernel: [112426.407047] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=334 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=314
Feb 11 04:36:46 saturn kernel: [112426.607294] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=461 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=441
Feb 11 04:36:46 saturn kernel: [112426.857553] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=461 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=441
Feb 11 04:36:47 saturn kernel: [112427.057905] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=270 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=250
Feb 11 04:36:47 saturn kernel: [112427.059407] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=206 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=186
Feb 11 04:36:47 saturn kernel: [112427.206919] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=105 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=85
Feb 11 04:36:47 saturn avahi-daemon[1658]: Registering new address record for fe80::224:8cff:fe44:49bc on eth0.*.
Feb 11 04:36:47 saturn kernel: [112427.607571] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=522 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=502
Feb 11 04:36:47 saturn kernel: [112427.803272] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=178 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=158
Feb 11 04:36:48 saturn kernel: [112428.053484] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=178 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=158
Feb 11 04:36:48 saturn kernel: [112428.258502] INPUT DROP/REJECT IN=eth0 OUT= MAC= SRC=10.1.1.3 DST=224.0.0.251 LEN=286 TOS=0x00 PREC=0x00 TTL=255 ID=
--
All Adults share the Responsibility
to help Raise Today's Children,
for they are Tomorrow's Society!
^ permalink raw reply
* Re: [PATCH] copy: adjust fiemap handling of sparse files
From: Pádraig Brady @ 2011-02-13 23:53 UTC (permalink / raw)
To: Jim Meyering, BTRFS MAILING LIST; +Cc: Coreutils
In-Reply-To: <4D55E03E.4070705@draigBrady.com>
Unfortunately, after checking BTRFS I see that fiemap
behaves differently to EXT4. IMHO the EXT4 operation
seems correct, and gives full info about the structure
of a file, which cp for example can use to efficiently
and accurately reproduce the structure at the destination.
On EXT4 (on kernel-2.6.35.11-83.fc14.i686) there are no extents
returned for holes in a file.
However on btrfs it does return an extent for holes?
So with btrfs there is no way to know an extent
is allocated but unwritten (zero), so one must
read and write all the data, rather than just
fallocating the space in the destination.
One can also see this with the following on btrfs:
$ fallocate -l 100000000 unwritten
$ truncate -s 100000000 sparse
$ dd count=3D1000 bs=3D100000 if=3D/dev/zero of=3Dzero
$ filefrag -vs *
=46ilesystem type is: 9123683e
=46ile size of sparse is 100000000 (24415 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 0 24415 unwritten,eof
sparse: 1 extent found
=46ile size of unwritten is 100000000 (24415 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 68160 12207
1 12207 92560 80366 12208 eof
unwritten: 2 extents found
=46ile size of zeros is 100000000 (24415 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 19360 20678
1 20678 43760 40037 3737 eof
zeros: 2 extents found
So is this expected?
Has this already been changed to match ext4?
=46or my own reference, I can probably skip performance
tests on (older) btrfs by checking `filefrag` output.
Also in `cp`, if we see an "unwritten extent" we should
probably create a hole rather than an empty allocation
by default. It's better to decrease file allocation
than increase it.
cheers,
P=E1draig.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-13 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102131634.40468.arnd@arndb.de>
On Sun, Feb 13, 2011 at 04:34:40PM +0100, Arnd Bergmann wrote:
> On Sunday 13 February 2011 18:53:02 Shawn Guo wrote:
> > On Fri, Feb 11, 2011 at 08:35:34AM +0800, Shawn Guo wrote:
> > >
> > > > > + unsigned present:1;
> > > >
> > > > Your card detection by polling through this variable is
> > > > really bad for power management. Is there really no interrupt
> > > > that gets triggered when installing or removing a card?
> > > >
> > > Good point. Will try to use interrupt.
> > >
> > I'm trying to use interrupt for card detection. But unfortunately,
> > I got stuck for some reason.
> >
> > There is a known issue that mx28 gpio interrupt from bank0 can not
> > work, because the pin bank0 irq number 127 was used in
> > get_irqnr_and_base (entry-macro.S) to tell there is no pending
> > interrupt any more.
> >
> > The mmc0 cd pin has no problem to trigger interrupt, as it's GPIO_2_9.
> > But mmc1 cd pin can not, because it's GPIO_0_20.
> >
> > So I probably have to stay with polling.
>
> I'm not sure if I understand completely. Is this a fundamental restriction,
> or something that only happens on a specific board?
>
This is a fundamental restriction.
> Maybe you can do both polling and interrupt driven card detection in
> the driver, and make it depend on a board-specific quirk. E.g. if you
> pass an interrupt number in the platform data, it should just use the
> interrupt, but if the interrupt is missing, you can fall back to
> polling.
>
I rewriting the code to use mmc core card detect polling framework.
static int mxs_mmc_get_cd(struct mmc_host *mmc)
{
struct mxs_mmc_host *host = mmc_priv(mmc);
return !(readl(host->base + HW_SSP_STATUS) &
BM_SSP_STATUS_CARD_DETECT);
}
static const struct mmc_host_ops mxs_mmc_ops = {
...
.get_cd = mxs_mmc_get_cd,
};
static int mxs_mmc_probe(struct platform_device *pdev)
{
...
mmc_caps |= MMC_CAP_NEEDS_POLL;
...
}
It looks pretty simple and mmc core code has taken care of the case
of power management. So if this looks fine to you, I will go for it
in v2 of the patch set.
Regards,
Shawn
^ permalink raw reply
* [Bug 26552] Screen flickering with 2.6.37 [ATI X1600]
From: bugzilla-daemon @ 2011-02-13 23:51 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-26552-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=26552
--- Comment #54 from Alex Deucher <alexdeucher@gmail.com> 2011-02-13 23:50:55 ---
Created an attachment (id=47732)
--> (https://bugzilla.kernel.org/attachment.cgi?id=47732)
final patch
Andrea, Daniel, Helber,
Thanks for all your help and testing. The attached patch is what I am
proposing goes upstream. Please verify it works properly for your systems.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
^ 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.