* Re: Panic:: handle_irq_event_percpu
From: Sander Eikelenboom @ 2011-10-22 14:57 UTC (permalink / raw)
To: Huang2, Wei; +Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk
In-Reply-To: <EE335F95F28A664DB4A21289D2AA053B01E6CBBD30@SAUSEXMBP01.amd.com>
Hello Wei,
Is this for xen 4.1.2 ?
All hunks of the patch seem to be rejected.
--
Sander
Wednesday, October 19, 2011, 8:27:55 PM, you wrote:
> This reminds me of 23768:09595fdf3638, which reverted WeiWang's patch of forcing perdev-intremap as default. Could you try the attached patch on your Xen 4.1 tree and test with patched xen.gz?
> Thanks,
> -Wei
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Sander Eikelenboom
> Sent: Wednesday, October 19, 2011 12:30 PM
> To: Huang2, Wei
> Cc: xen-devel@lists.xensource.com; Konrad Rzeszutek Wilk
> Subject: Re: [Xen-devel] Panic:: handle_irq_event_percpu
> Hello Wei,
> Result is that using only "1" or "1" in combination with "2" always result in SATA I/O errors, so that doesn't boot.
> Haven't tried rebooting a lot of times without iommu yet.
> (the reason i bought the 890fx board in the first place)
> Will try that a few times when i have some more time.
> --
> Sander
> Wednesday, October 19, 2011, 6:38:38 PM, you wrote:
>> It looks similar.
>> Hi Sander, could you please test your system with the following options?
>> 1. iommu=amd-iommu-perdev-intremap in xen.gz GRUB entry
>> 2. pci=nosmi in pvops GRUB entry
>> 3. iommu=0 in xen.gz GRUB entry [optional, only if (1) doesn't work for you]
>> We were seeing an issue which was caused by messed-up interrupt remap table. George Dunlap's perdev interrupt map solved our problem.
>> Thanks,
>> -Wei
>> -----Original Message-----
>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>> Sent: Wednesday, October 19, 2011 11:08 AM
>> To: Sander Eikelenboom; Huang2, Wei
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Panic:: handle_irq_event_percpu
>> On Tue, Oct 18, 2011 at 08:55:19PM +0200, Sander Eikelenboom wrote:
>>> Hi Konrad,
>>>
>>> On my system (AND phenom x6, 8gb mem) running xen 4.1.2-rc3
>>> and a custom kernel based on:
>>>
>>> - your linux-next branch
>>> - pulled in your apci/cpufreq branch
>>> - pulled in latest patches from linuses tree
>> Wei,
>> Are those similar to what you had been seeing?
>>>
>>> I'm experiencing infrequent panics at boot (say 1 out of 10 or 20 boots), doesn't seem to matter if it's a cold or a warm boot.
>>> It always seem to happen during or shortly after booting. When it doesn't occur then, it can run for at least several days/weeks (haven't seen it panic then).
>>> It doesn't seem to happen at a particular point at or shortly after booting, but it happens before starting any guests
>>>
>>> Unfortunately i haven't had serial console enabled at these times, but i have made some photo's.
>>> The first 3 times it locked completely before being able to print a stacktrace, the 4th time it did (although the photo is a bit unsharp).
>>>
>>>
>>> So all in all, it kind of strange, i hope you can figure something out from the stacktrace, if not, i will see if i can try with serial console attached.
>>>
>>> --
>>> Sander
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
--
Best regards,
Sander mailto:linux@eikelenboom.it
^ permalink raw reply
* Re: [Multipath] Round-robin performance limit
From: Pasi Kärkkäinen @ 2011-10-22 15:02 UTC (permalink / raw)
To: device-mapper development; +Cc: jsullivan
In-Reply-To: <CANtKax+PzU=yVepQh3Kq7NK671-bSpYfms2Xu_YgdXQ0cDG6kA@mail.gmail.com>
On Wed, Oct 05, 2011 at 03:54:35PM -0400, Adam Chasen wrote:
> John,
> I am limited in a similar fashion. I would much prefer to use multibus
> multipath, but was unable to achieve bandwidth which would exceed a
> single link even though it was spread over the 4 available links. Were
> you able to gain even a similar performance of the RAID0 setup with
> the multibus multipath?
>
Utilizing multiple links works with for example this setup:
- VMware ESXi 4.1 software iSCSI initiator.
- Dell Equallogic iSCSI target.
The steps needed for ESXi are:
- Configure multiple VMkernel (vmkX) IP interfaces.
- Configure ESXi iscsi initiator to use (bind to) all the vmkX interfaces.
- Configure the path selection policy to be RR (RoundRobin).
- Configure multipath to switch paths after 3 IOs.
The same should work with Linux dm-multipath.
-- Pasi
> Thanks,
> Adam
>
> On Tue, Oct 4, 2011 at 11:07 PM, John A. Sullivan III
> <jsullivan@opensourcedevel.com> wrote:
> > On Tue, 2011-10-04 at 16:19 -0400, Adam Chasen wrote:
> >> Unfortunately even with playing around with various settings, queues,
> >> and other techniques, I was never able to exceed the bandwidth of more
> >> than one of the Ethernet links when accessing a single multipathed
> >> LUN.
> >>
> >> When communicating with two different multipathed LUNs, which present
> >> as two different multipath devices, I can saturate two links, but it
> >> is still a one to one ratio of multipath devices to link saturation.
> >>
> >> After further research on multipathing, it appears people are using md
> >> raid to achieve multipathed devices. My initial testing of using raid0
> >> md-raid device produces the behavior I expect of multipathed devices.
> >> I can easily saturate both links during read operations.
> >>
> >> I feel using md-raid is a less elegant solution than using
> >> dm-multipath, but it will have to suffice until someone can provide me
> >> some additional guidance.
> >>
> >> Thanks,
> >> Adam
> > We recently changed from the RAID0 approach to multipath multibus.
> > RAID0 did seem to give more even performance over a variety of IO
> > patterns but it had a critical flaw. We could not use the snapshot
> > capabilities of the SAN because we could never be certain of
> > snapshotting the RAID0 disks in a transactionally consistent state. If
> > I have four disk in a RAID0 array and snapshot them all, how can I be
> > assured that I have not done something like written two of three stripes
> > and no parity. This was our singular reason for discarding RAID0 over
> > iSCSI for multipath multibus - John
> >
> >>
> >> On Mon, Oct 3, 2011 at 11:08 PM, Adam Chasen <adam@chasen.name> wrote:
> >> > Malahal,
> >> > After your mentioning bio vs request based I attempted to determine if
> >> > my kernel contains the request based mpath. It seems in 2.6.31 all
> >> > mpath was switched to request based. I have a kernel 2.6.31+ (actually
> >> > .35 and .38), so I believe I have requrest-based mpath.
> >> >
> >> > All,
> >> > There also appears to be a new multipath configuration option
> >> > documented in the RHEL 6 beta documentation:
> >> > rr_min_io_rq Specifies the number of I/O requests to route to a path
> >> > before switching to the next path in the current path group, using
> >> > request-based device-mapper-multipath. This setting should be used on
> >> > systems running current kernels. On systems running kernels older than
> >> > 2.6.31, use rr_min_io. The default value is 1.
> >> >
> >> > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/DM_Multipath/config_file_multipath.html
> >> >
> >> > I have not tested using this setting vs rr_min_io yet or even if my
> >> > system supports the configuration directive.
> >> >
> >> > If I trust some of the claims of several VMware ESX iscsi multipath
> >> > setups, it is possible (possibly using different software) to gain a
> >> > multiplicative throughput by adding additional Ethernet links. This
> >> > makes me hopeful that we can do this with open-iscsi and dm-mulitpath
> >> > as well.
> >> >
> >> > It could be something obvious I am missing, but it appears a lot of
> >> > people experience this same issue.
> >> >
> >> > Thanks,
> >> > Adam
> >> >
> >> > On Tue, May 3, 2011 at 6:12 AM, John A. Sullivan III
> >> > <jsullivan@opensourcedevel.com> wrote:
> >> >> On Mon, 2011-05-02 at 22:04 -0700, Malahal Naineni wrote:
> >> >>> John A. Sullivan III [jsullivan@opensourcedevel.com] wrote:
> >> >>> > I'm also very curious about your findings on rr_min_io. I cannot find
> >> >>> > my benchmarks but we tested various settings heavily. I do not recall
> >> >>> > if we saw more even scaling with 10 or 100. I remember being surprised
> >> >>> > that performance with it set to 1 was poor. I would have thought that,
> >> >>> > in a bonded environment, changing paths per iSCSI command would give
> >> >>> > optimal performance. Can anyone explain why it does not?
> >> >>>
> >> >>> rr_min_io of 1 will give poor performance if your multipath kernel
> >> >>> module doesn't support request based multipath. In those BIO based
> >> >>> multipath, multipath receives 4KB requests. Such requests can't be
> >> >>> coalesced if they are sent on different paths.
> >> >> <snip>
> >> >> Ah, that makes perfect sense and why 3 seems to be the magic number in
> >> >> Linux (4000 / 1460 (or whatever IP payload is)). Does that change with
> >> >> Jumbo frames? In fact, how would that be optimized in Linux?
> >> >>
> >> >> 9KB seems to be a reasonable common jumbo frame value for various
> >> >> vendors and that should contain two pages but, I would guess, Linux
> >> >> can't utilize it as each block must be independently acknowledged. Is
> >> >> that correct? Thus a frame size of a little over 4KB would be optimal
> >> >> for Linux?
> >> >>
> >> >> Would that mean that rr_min_io of 1 would become optimal? However, if
> >> >> each block needs to be acknowledged before the next is sent, I would
> >> >> think we are still latency bound, i.e., even if I can send four requests
> >> >> down four separate paths, I cannot send the second until the first has
> >> >> been acknowledged and since I can easily place four packets on the same
> >> >> path within the latency period of four packets, multibus gives me
> >> >> absolutely no performance advantage for a single iSCSI stream and only
> >> >> proves useful as I start multiplexing multiple iSCSI streams.
> >> >>
> >> >> Is that analysis correct? If so, what constitutes a separate iSCSI
> >> >> stream? Are two separate file requests from the same file systems to the
> >> >> same iSCSI device considered two iSCSI streams and thus can be
> >> >> multiplexed and benefit from multipath or are they considered all part
> >> >> of the same iSCSI stream? If they are considered one, do they become two
> >> >> if they reside on different partitions and thus different file systems?
> >> >> If not, then do we only see multibus performance gains between a single
> >> >> file system host and a single iSCSI host when we use virtualization each
> >> >> with their own iSCSI connection (as opposed to using iSCSI connections
> >> >> in the underlying host and exposing them to the virtual machines as
> >> >> local storage)?
> >> >>
> >> >> I hope I'm not hijacking this thread and realize I've asked some
> >> >> convoluted questions but optimizing multibus through bonded links for
> >> >> single large hosts is still a bit of a mystery to me. Thanks - John
> >> >>
> >> >> --
> >> >> dm-devel mailing list
> >> >> dm-devel@redhat.com
> >> >> https://www.redhat.com/mailman/listinfo/dm-devel
> >> >>
> >> >
> >>
> >> --
> >> dm-devel mailing list
> >> dm-devel@redhat.com
> >> https://www.redhat.com/mailman/listinfo/dm-devel
> >
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/dm-devel
> >
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Alexander Graf @ 2011-10-22 15:07 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Kevin Wolf, qemu-devel, avi
In-Reply-To: <4EA1BD95.8030205@redhat.com>
On 21.10.2011, at 11:44, Paolo Bonzini wrote:
> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
>> Avi complained that not even writing out qcow2's cache on bdrv_flush() made
>> cache=unsafe too unsafe to be useful. He's got a point.
>
> Why? cache=unsafe is explicitly allowing to s/data/manure/ on crash.
Exactly, but not on kill. By not flushing internal caches you're almost guaranteed to get an inconsistent qcow2 image.
> If you do this for raw-posix, you need to do it for all protocols.
Only for the ones that actually do flushes to the block layer. The idea is that while QEMU dies the OS can still finish writing unflushed blocks.
Alex
^ permalink raw reply
* Re: RFC: dm-switch target [v2]
From: Pasi Kärkkäinen @ 2011-10-22 15:08 UTC (permalink / raw)
To: Jim_Ramsay; +Cc: dm-devel, Parind_Shah, Jason_Shamberger, Kevin_OKelley
In-Reply-To: <32C294CE27383749AAB52C2549D4120C016193A3B2@AUSX7MCPS306.AMER.DELL.COM>
On Fri, Sep 02, 2011 at 05:56:11PM -0500, Jim_Ramsay@DELL.com wrote:
> Pasi Kärkkäinen wrote:
> >On Wed, Aug 31, 2011 at 04:19:24PM -0400, Jim Ramsay wrote:
> >> We propose a new DM target, dm-switch, which can be used to
> >> efficiently implement a mapping of IOs to underlying block devices in
> >> scenarios where there are: (1) a large number of address regions, (2)
> >> a fixed size of these address regions, (3) no pattern than allows for
> >> a compact description with something like the dm-stripe target.
> >
> > Great, I've been waiting for this module :)
>
> Thanks, it's great to hear the interest!
>
> > Do you guys have some userland tool/script to populate the page
> > table in dm-switch, or is there some other way to test this
> > (with eql storage) ?
>
> We are planning on providing some sample code, which will
> demonstrate how to upload a page table from userland via the
> netlink socket.
>
Hello again,
Any news about this sample code?
I noticed you guys just posted v3 of the patch,
so it would be nice to try it out.
-- Pasi
^ permalink raw reply
* Re: Problem with log which are corrupted and need help with hitcount and FORWARD rules
From: Azerty Ytreza @ 2011-10-22 15:11 UTC (permalink / raw)
To: Andrew Beverley; +Cc: netfilter
In-Reply-To: <1319293517.26402.6312.camel@andybev-desktop>
Just mean gateway/firewall server that all the traffic passes through.
No doesn't work ... The port is blocked when I try these rules (copy
of the INPUT rules) :
iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
NEW -m recent --set
iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
NEW -m recent --update --seconds 600 --hitcount 1 -j DROP
iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
NEW,ESTABLISHED -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j
DNAT --to-destination 192.168.1.2:443
If I try that, the port is always open and hitcount doesn't work :
iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
NEW -m recent --set
iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
NEW -m recent --update --seconds 600 --hitcount 1 -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j
DNAT --to-destination 192.168.1.2:443
Thank you for the picture ! It's very interesting :)
And sorry but I have never user mailing list. I don't known how it's
work exactly :(
I put in copy this time :)
Thank you for your help !
On 10/22/11, Andrew Beverley <andy@andybev.com> wrote:
> On Sat, 2011-10-22 at 16:14 +0200, Azerty Ytreza wrote:
>> "What exactly are you trying to achieve? If you're changing to a FORWARD
>> rule then I assume that you are trying to adapt your rules in order to
>> block connections destined for a remote server, rather than the local
>> host?"
>>
>> I want to limit the number of connections which passtrough the host.
>
> Okay, in which case you do want FORWARD.
>
>> Yes, I can block that on the remote server but I prefer on the local
>> if it's possible.
>
> Do you really mean "local" (in which case you want OUTPUT) or do you
> just mean on your gateway/firewall server that all the traffic passes
> through?
>
>>
>> "Do you really mean UDP?"
>>
>> No, it's an error sorry. I have copy/paste other rules and adapt rules
>> but forget to change udp to tcp.
>
> Okay, so it's working now?
>
>> "You've got a mixture of INPUT and FORWARD. Is that what you want?
>> Remember that packets will never transverse both the INPUT and FORWARD
>> chains."
>>
>> The port 443 is blocked by default it's for that which I open and
>> after redirect. If I made only a FORWARD it's open directly the port
>> without INPUT rules ?
>
> It depends where you're blocking it. What's the default FORWARD rule?
> ACCEPT?
>
> The bottom line is that you need all your rules in FORWARD *or* INPUT. A
> picture paints a thousand words:
>
> http://jengelh.medozas.de/images/nf-packet-flow.png
>
> Or for a simpler (out of date) version:
>
> http://www.docum.org/docum.org/kptd/
>
>>
>>
>> Thank you for your response !
>
> No problem, but please put your responses in-line to the original email
> rather than copying and pasting to the top! Oh, and copy the list as
> well.
>
> Andy
>
>
>
^ permalink raw reply
* Re: [patch net-next V2] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-22 15:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, bhutchings, shemminger, fubar, andy, tgraf,
ebiederm, mirqus, kaber, greearb, jesse, fbl, benjamin.poirier,
jzupka
In-Reply-To: <1319208237.32161.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>> +
>> +/************************
>> + * Rx path frame handler
>> + ************************/
>> +
>> +/* note: already called with rcu_read_lock */
>> +static rx_handler_result_t team_handle_frame(struct sk_buff **pskb)
>> +{
>> + struct sk_buff *skb = *pskb;
>> + struct team_port *port;
>> + struct team *team;
>> + rx_handler_result_t res = RX_HANDLER_ANOTHER;
>> +
>> + skb = skb_share_check(skb, GFP_ATOMIC);
>> + if (!skb)
>> + return RX_HANDLER_CONSUMED;
>> +
>> + *pskb = skb;
>> +
>> + port = team_port_get_rcu(skb->dev);
>> + team = port->team;
>> +
>> + if (team->mode_ops.receive)
>
>Hmm, you need ACCESS_ONCE() here or rcu_dereference()
>
>See commit 4d97480b1806e883eb (bonding: use local function pointer of
>bond->recv_probe in bond_handle_frame) for reference
I do not think so. Because mode_ops.receive changes only from
__team_change_mode() and this can be called only in case no ports are in
team. And team_port_del() calls synchronize_rcu().
Jirka
>
>> + res = team->mode_ops.receive(team, port, skb);
>> +
>> + if (res == RX_HANDLER_ANOTHER) {
>> + struct team_pcpu_stats *pcpu_stats;
>> +
>> + pcpu_stats = this_cpu_ptr(team->pcpu_stats);
>> + u64_stats_update_begin(&pcpu_stats->syncp);
>> + pcpu_stats->rx_packets++;
>> + pcpu_stats->rx_bytes += skb->len;
>> + if (skb->pkt_type == PACKET_MULTICAST)
>> + pcpu_stats->rx_multicast++;
>> + u64_stats_update_end(&pcpu_stats->syncp);
>> +
>> + skb->dev = team->dev;
>> + } else {
>> + this_cpu_inc(team->pcpu_stats->rx_dropped);
>> + }
>> +
>> + return res;
>> +}
>> +
^ permalink raw reply
* Re: [PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)
From: Christoph @ 2011-10-22 15:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Theodore Ts'o, LKML, xfs, Christoph Hellwig, Nigel Cunningham,
Pavel Machek, linux-fsdevel, Linux PM mailing list, linux-ext4
In-Reply-To: <201109260010.50649.rjw@sisk.pl>
> PM / Freezer: Freeze filesystems while freezing processes (v2)
>
> On Sunday, August 07, 2011, Dave Chinner wrote:
>> On Sat, Aug 06, 2011 at 11:17:18PM +0200, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki <rjw@sisk.pl>
>>>
>>> Freeze all filesystems during the freezing of tasks by calling
>>> freeze_bdev() for each of them and thaw them during the thawing of
>>> tasks with the help of thaw_bdev().
>>>
>>> This is needed by hibernation, because some filesystems (e.g. XFS)
>>> deadlock with the preallocation of memory used by it if the memory
>>> pressure caused by it is too heavy.
>>>
...
>
> Below is an alternative fix, the changelog pretty much explains the
> idea.
>
> I've tested it on Toshiba Portege R500, but I don't have an XFS
> partition to verify that it really helps, so I'd appreciate it if
> someone able to reproduce the original issue could test it and report
> back.
Hi Rafael!
Well, the kernel bugtracker is still down and I just like to post my
experience with kernel (x64) v3.1-rc8/9 + patches. My machine is a
MacBookPro, doomed with 4GB RAM running debian.
Bug #1
on the way to hibernate, machine hangs on
"PM: Preallocating image memory..."
this patch worked for me now for weeks:
"[PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)"
https://lkml.org/lkml/2011/9/24/77
I was able to reproduce this bug with virtualbox and tested the patch ~40
cycles.
Bug#2
on resume from hibernate, hard reset (x64 only):
http://marc.info/?l=linux-kernel&m=131653513414314&w=2
With this patch I haven't got this issue again the last weeks.
I wasn't able to reproduce this bug with virtualbox.
I only got one pm-hibernate issue. Last line:
Disabling non-boot CPUs ...
This time I've enabled debug hung task :)
schedule_timeout
...
workqueue_cpu_callback
notifier_call_chain
...
__cpu_notify
_cpu_down
printk
disable_nonboot_cpus
hibernation_snapshot
hibernate
...
Any other idea besides the possibility it's caused by evil earth
radiation, isn't it?
Gruss,
chris
On 26.09.2011 00:10, Rafael J. Wysocki wrote:
> On Sunday, September 25, 2011, Christoph wrote:
>> On 25.09.2011 15:32, Rafael J. Wysocki wrote:
>>> On Sunday, September 25, 2011, Christoph wrote:
>>>> test results of the patch below:
>>>>
>>>> 1. real machine
>>>>
>>>> suspends fine but on wakeup, after loading image: hard reset. nvidia
>>>> gpu => disabled compitz => wakeup worked two times.
>>>
>>> Hmm, so there's a separate bug related to NVidia I guess.
>>
>> Maybe.
>>
>> Just made another test: the machine (macbook) woke up, loaded image, thaw.
>> It got stuck at vt#1, displaying console with login. Cursor blinking, but
>> no (usb) keyboard or network enabled. Bricked?!!
>>
>>
>> On the other hand I've got another box with nvidia gpu:
>>
>> debian5 32bit
>> 2.6.38.2+ #3 SMP Fri Apr 1
>> nvidia 260.19.36
>>
>> It's up since I compiled the kernel: I use it twice a week and I kept it
>> freezed all the time. It was solid rock until today: hard reset on resume.
>> WTF? (I remember this version combo was stable on the macbook but the
>> kernel lacks a solid wireless driver).
>
> If that's an x86_64 system, there is a known bug causing problems like
> this to happen. There's a patch fixing it, but not conclusive:
> http://marc.info/?l=linux-kernel&m=131653513414314&w=2
>
> Thanks,
> Rafael
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)
From: Christoph @ 2011-10-22 15:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Theodore Ts'o, LKML, xfs, Christoph Hellwig, Nigel Cunningham,
Pavel Machek, linux-fsdevel, Linux PM mailing list, linux-ext4
In-Reply-To: <201109260010.50649.rjw@sisk.pl>
> PM / Freezer: Freeze filesystems while freezing processes (v2)
>
> On Sunday, August 07, 2011, Dave Chinner wrote:
>> On Sat, Aug 06, 2011 at 11:17:18PM +0200, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki <rjw@sisk.pl>
>>>
>>> Freeze all filesystems during the freezing of tasks by calling
>>> freeze_bdev() for each of them and thaw them during the thawing of
>>> tasks with the help of thaw_bdev().
>>>
>>> This is needed by hibernation, because some filesystems (e.g. XFS)
>>> deadlock with the preallocation of memory used by it if the memory
>>> pressure caused by it is too heavy.
>>>
...
>
> Below is an alternative fix, the changelog pretty much explains the
> idea.
>
> I've tested it on Toshiba Portege R500, but I don't have an XFS
> partition to verify that it really helps, so I'd appreciate it if
> someone able to reproduce the original issue could test it and report
> back.
Hi Rafael!
Well, the kernel bugtracker is still down and I just like to post my
experience with kernel (x64) v3.1-rc8/9 + patches. My machine is a
MacBookPro, doomed with 4GB RAM running debian.
Bug #1
on the way to hibernate, machine hangs on
"PM: Preallocating image memory..."
this patch worked for me now for weeks:
"[PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)"
https://lkml.org/lkml/2011/9/24/77
I was able to reproduce this bug with virtualbox and tested the patch ~40
cycles.
Bug#2
on resume from hibernate, hard reset (x64 only):
http://marc.info/?l=linux-kernel&m=131653513414314&w=2
With this patch I haven't got this issue again the last weeks.
I wasn't able to reproduce this bug with virtualbox.
I only got one pm-hibernate issue. Last line:
Disabling non-boot CPUs ...
This time I've enabled debug hung task :)
schedule_timeout
...
workqueue_cpu_callback
notifier_call_chain
...
__cpu_notify
_cpu_down
printk
disable_nonboot_cpus
hibernation_snapshot
hibernate
...
Any other idea besides the possibility it's caused by evil earth
radiation, isn't it?
Gruss,
chris
On 26.09.2011 00:10, Rafael J. Wysocki wrote:
> On Sunday, September 25, 2011, Christoph wrote:
>> On 25.09.2011 15:32, Rafael J. Wysocki wrote:
>>> On Sunday, September 25, 2011, Christoph wrote:
>>>> test results of the patch below:
>>>>
>>>> 1. real machine
>>>>
>>>> suspends fine but on wakeup, after loading image: hard reset. nvidia
>>>> gpu => disabled compitz => wakeup worked two times.
>>>
>>> Hmm, so there's a separate bug related to NVidia I guess.
>>
>> Maybe.
>>
>> Just made another test: the machine (macbook) woke up, loaded image, thaw.
>> It got stuck at vt#1, displaying console with login. Cursor blinking, but
>> no (usb) keyboard or network enabled. Bricked?!!
>>
>>
>> On the other hand I've got another box with nvidia gpu:
>>
>> debian5 32bit
>> 2.6.38.2+ #3 SMP Fri Apr 1
>> nvidia 260.19.36
>>
>> It's up since I compiled the kernel: I use it twice a week and I kept it
>> freezed all the time. It was solid rock until today: hard reset on resume.
>> WTF? (I remember this version combo was stable on the macbook but the
>> kernel lacks a solid wireless driver).
>
> If that's an x86_64 system, there is a known bug causing problems like
> this to happen. There's a patch fixing it, but not conclusive:
> http://marc.info/?l=linux-kernel&m=131653513414314&w=2
>
> Thanks,
> Rafael
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [PATCH RFC] try to create KBUILD_OUTPUT automatically
From: Peter Foley @ 2011-10-22 15:12 UTC (permalink / raw)
To: Linux Kbuild Mailing List, Linux Kernel Mailing List, mmarek
This patch makes it possible to execute make O=work instead of
mkdir work
make O=work
Signed-off-by: Peter Foley <pefoley2@verizon.net>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 2652089..a4769ac 100644
--- a/Makefile
+++ b/Makefile
@@ -117,7 +117,7 @@ ifneq ($(KBUILD_OUTPUT),)
# Invoke a second make in the output directory, passing relevant variables
# check that the output directory actually exists
saved-output := $(KBUILD_OUTPUT)
-KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
+KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) && /bin/pwd)
$(if $(KBUILD_OUTPUT),, \
$(error output directory "$(saved-output)" does not exist))
--
1.7.7
^ permalink raw reply related
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Albert ARIBAUD @ 2011-10-22 15:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110221619.55305.marek.vasut@gmail.com>
Le 22/10/2011 16:19, Marek Vasut a ?crit :
> On Saturday, October 22, 2011 11:48:43 AM Albert ARIBAUD wrote:
>> Le 22/10/2011 03:18, Marek Vasut a ?crit :
>>> On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote:
>>>> Hi Marek,
>>>>
>>>> Le 22/10/2011 02:16, Marek Vasut a ?crit :
>>>>> This patch series reworks the debug() and debugX() macro in
>>>>> include/common.h to be compatible with GCC 4.6.
>>>>>
>>>>> This series needs further discussion:
>>>>> * Some files suffer size growth with gcc4.2, why ?
>>>>>
>>>>> - Possibility is that the GCC4.2 is incapable to optimize code out
>>>>> so deep
>>>>>
>>>>> * Does this change break any platforms? Compile tested on PowerPC.
>>>>>
>>>>> - Please run MAKEALL on your platforms to test this.
>>>>
>>>> Any git branch we could pull and rebase on our trees rather than am'ing
>>>> 39 patches one by one?
>>>
>>> Please try:
>>>
>>> git://git.denx.de/u-boot-marex.git , "debug" branch.
>>>
>>> Cheers
>>
>> A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not
>> building properly, from 74 to 141 (out of a total of 248).
>
> This was expected ... will fix.
Much welcome. :)
>> Of the 67 boards, many show , essentially due to a lot of printf format
>> warnings such as:
>>
>> ks8695eth.c: In function 'ks8695_eth_send':
>> ks8695eth.c:199: warning: format '%x' expects type 'unsigned int', but
>> argument 4 has type 'volatile void *'
>>
>> (in cm4008, cm41xx), or
>>
>> lcd.c: In function 'lcd_setmem':
>> lcd.c:446: warning: format '%d' expects type 'int', but argument 2 has
>> type 'u_long'
>> lcd.c:446: warning: format '%d' expects type 'int', but argument 3 has
>> type 'u_long'
>>
>> (in at91sam9261ek_nandflash). Another, different, case is smdk2410:
>>
>> s3c2410_nand.c: In function 's3c2410_hwcontrol':
>> s3c2410_nand.c:59: error: 'DEBUG' undeclared (first use in this function)
>> s3c2410_nand.c:59: error: (Each undeclared identifier is reported only once
>> s3c2410_nand.c:59: error: for each function it appears in.)
>> s3c2410_nand.c: In function 's3c2410_dev_ready':
>> s3c2410_nand.c:86: error: 'DEBUG' undeclared (first use in this function)
>> s3c2410_nand.c: In function 'board_nand_init':
>>
>> Seems like you're trading some warnings against some others, depending
>> on the compiler. :(
>
> Not trading, the typechecking wasn't there and now that it is there, these kind
> of warnings keep popping up. Did you ever try to build those boards with DEBUG
> enabled?
Not the whole code; I only enabled debug in very specific areas.
> Cheers
Amicalement,
--
Albert.
^ permalink raw reply
* Re: Problem with log which are corrupted and need help with hitcount and FORWARD rules
From: Andrew Beverley @ 2011-10-22 15:27 UTC (permalink / raw)
To: Azerty Ytreza; +Cc: netfilter
In-Reply-To: <CACMGiwaJ69TsOb6gVH_GXLk09yKhxqLExa_s-NXhG8d9M2z7hQ@mail.gmail.com>
On Sat, 2011-10-22 at 17:11 +0200, Azerty Ytreza wrote:
> Just mean gateway/firewall server that all the traffic passes through.
>
> No doesn't work ... The port is blocked when I try these rules (copy
> of the INPUT rules) :
>
> iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
> NEW -m recent --set
> iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
> NEW -m recent --update --seconds 600 --hitcount 1 -j DROP
You've got a hitcount of 1. Don't you mean 10 as you had in your first
set of rules?
> And sorry but I have never user mailing list. I don't known how it's
> work exactly :(
No problem, but please don't put your reply at the top. Put it either
within or at the bottom of the quoted email, just like I have for this
email. It makes it easier for other people to follow the conversation if
they've joined late or are reading it in the archives :)
Andy
^ permalink raw reply
* Re: A Plumber’s Wish List for Linux
From: Lennart Poettering @ 2011-10-22 15:28 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Paul Menage, Kay Sievers, linux-kernel, harald, david, greg
In-Reply-To: <20111022102126.GA2811@somewhere.feld.cvut.cz>
On Sat, 22.10.11 12:21, Frederic Weisbecker (fweisbec@gmail.com) wrote:
> If you really need to stop any forks in a cgroup, then a cgroup core feature
> handling that very single purpose would be better and more efficient.
We'd be happy with that and this is what we originally suggested actually.
> That said I'm not really sure why you're using cgroups in Systemd.
We want to reliably label processes in a hierarchial way, so that this
is inherited by all child processes, cannot be overriden by unprivileged
code (subject to some classic Unix access control handling) and get
notifications when such a label stops referring to any process. We use
that for sticking the service name on a process, so that all CGI
processes of Apache are automatically assigned the same service as
apache itself. And we want a notification when all of apache's processes
die. And we also want to be able to kill Apache compeltely by killing
all its processes.
cgroups provides us with all of that, though the last two items only in
a suboptimal way: notification of cgroups running empty is ugly, since
it is done by spawning a usermode helper (we'd prefer a netlink msg or
so), and the process killing is a bit racy.
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* Kernel driver r8169 not working for Realtek 8111E onboard network card
From: Adrian George Sav @ 2011-10-22 15:22 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello.
I am having trouble with the r8169 kernel driver for Realtek 8111E network card.
The NIC works intermittently and horribly with this driver. Unusable.
Below is my config. I am happy to provide any and every other necessary information to help in solving this.
Thank you.
Motherboard: ASUS P8P67(REV 3.1)
Kernel: up to 2.6.39
lspci -vv:
------------------------------------------------------------------------------------------------------------
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard [Realtek RTL8111E]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 66
Region 0: I/O ports at d000 [size=256]
Region 2: Memory at d0004000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at d0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000feeff00c Data: 417a
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 00, will not decode more.
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 01-00-00-00-68-4c-e0-00
Kernel driver in use: r8169
Kernel modules: r8169
------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: make check
From: Martin Pitt @ 2011-10-22 15:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111021220133.GA8417@linux1>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
William Hubbs [2011-10-21 17:01 -0500]:
> is "make check" meant to be run on release tarballs, or just in the git
> repository?
It's meant to work on both. That's what 'make distcheck' verifies, too.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: No line out on latest Mac Mini
From: Jérémy Lal @ 2011-10-22 15:30 UTC (permalink / raw)
To: John Frankish; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <654DF80AD31A344E93DBCC6280BD6DEF2226DD53@NL0230MBX08N1.DIR.slb.com>
On 22/10/2011 16:01, John Frankish wrote:
>> Hi,
>> i have an imac 12,2 (2011) and i had to change GPIO with hda_analyzer to get
>> some sound on line out.
>>
>> Jérémy.
>
> Thanks - I see something like this with hda_analyser:
>
> Global Input Amplifier Caps-> <- Global Output Amplifier Caps
>
> GPIO
> out-dir enable unsol sticky wake data
> [0]
> [1] x x [x]
> [2]
> [3] x x x
>
> ..where [1] data enables/disables line out and [3] data enables/disables the internal speaker.
> [1] data was not checked and doing so got things working - a big thank you for this.
>
> Line out continues to work after closing hda_analyser, but do you know what it actually changes so I
> Can make it permanent across reboots?
A patch that applies to recent kernels :
https://gist.github.com/1306112
The pincfg won't probably apply for you -- but it show how you can hack something.
Jérémy.
^ permalink raw reply
* Re: Build Failure - signgp
From: Russell Morris @ 2011-10-22 15:24 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <CAMKF1sqVz+CXO=7f-NQVi1dUJo+w8Fk6=BkbF+neKUpLkpWErw@mail.gmail.com>
Makes sense - thanks!!!
On Sat, 10/22/2011 09:17 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Sat, Oct 22, 2011 at 6:35 AM, Russell Morris
> <openembedded@rkmorris.us> wrote:
> > Hi,
> > This worked - thanks!!!
> > I have one last question though ... :-). This is two patches that I have applied (that both work, great news there) - but why are they not applied to the git repository? Just curious, that's all.
>
> they will be applied soon if not applied yet.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
From gcho-openembedded-devel@m.gmane.org Sat Oct 22 18:16:10 2011
Received: from lo.gmane.org ([80.91.229.12])
by linuxtogo.org with esmtp (Exim 4.72)
(envelope-from <gcho-openembedded-devel@m.gmane.org>)
id 1RHeF0-0007G2-SL for openembedded-devel@lists.openembedded.org;
Sat, 22 Oct 2011 18:16:10 +0200
Received: from list by lo.gmane.org with local (Exim 4.69)
(envelope-from <gcho-openembedded-devel@m.gmane.org>)
id 1RHe9B-0000kv-9S for openembedded-devel@lists.openembedded.org;
Sat, 22 Oct 2011 18:10:09 +0200
Received: from ip545070eb.adsl-surfen.hetnet.nl ([84.80.112.235])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <openembedded-devel@lists.openembedded.org>;
Sat, 22 Oct 2011 18:10:09 +0200
Received: from koen by ip545070eb.adsl-surfen.hetnet.nl with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <openembedded-devel@lists.openembedded.org>;
Sat, 22 Oct 2011 18:10:09 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: openembedded-devel@lists.openembedded.org
From: Koen Kooi <koen@dominion.thruhere.net>
Date: Sat, 22 Oct 2011 18:09:50 +0200
Lines: 19
Message-ID: <j7upse$e5o$1@dough.gmane.org>
References: <1319210443657408500@rkmorris.us>
<CAMKF1sqUsuZ5_rmcsq5o1FsYw42mz9VVC
^ permalink raw reply
* Re: Problem with log which are corrupted and need help with hitcount and FORWARD rules
From: Azerty Ytreza @ 2011-10-22 15:33 UTC (permalink / raw)
To: Andrew Beverley; +Cc: netfilter
In-Reply-To: <1319297250.26402.6316.camel@andybev-desktop>
**********************************************************************************************
> Just mean gateway/firewall server that all the traffic passes through.
>
> No doesn't work ... The port is blocked when I try these rules (copy
> of the INPUT rules) :
>
> iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
> NEW -m recent --set
> iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
> NEW -m recent --update --seconds 600 --hitcount 1 -j DROP
You've got a hitcount of 1. Don't you mean 10 as you had in your first
set of rules?
> And sorry but I have never user mailing list. I don't known how it's
> work exactly :(
No problem, but please don't put your reply at the top. Put it either
within or at the bottom of the quoted email, just like I have for this
email. It makes it easier for other people to follow the conversation if
they've joined late or are reading it in the archives :)
**********************************************************************************************
Yes it's for test. The first time should work, the second request
should be blocked for 600sec.
But never block the connection so doesn't work :(
I doesnt choose... I receive an email and reply ...
On 10/22/11, Andrew Beverley <andy@andybev.com> wrote:
> On Sat, 2011-10-22 at 17:11 +0200, Azerty Ytreza wrote:
>> Just mean gateway/firewall server that all the traffic passes through.
>>
>> No doesn't work ... The port is blocked when I try these rules (copy
>> of the INPUT rules) :
>>
>> iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
>> NEW -m recent --set
>> iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
>> NEW -m recent --update --seconds 600 --hitcount 1 -j DROP
>
> You've got a hitcount of 1. Don't you mean 10 as you had in your first
> set of rules?
>
>> And sorry but I have never user mailing list. I don't known how it's
>> work exactly :(
>
> No problem, but please don't put your reply at the top. Put it either
> within or at the bottom of the quoted email, just like I have for this
> email. It makes it easier for other people to follow the conversation if
> they've joined late or are reading it in the archives :)
>
> Andy
>
>
>
^ permalink raw reply
* In search of a capture card or DVI with compression
From: Fabian Sturm @ 2011-10-22 15:25 UTC (permalink / raw)
To: linux-media
Hi,
I searched the web for quite some time for a good video capture card but
did not find something for linux.
What I want to do is to capture the output of 4 pcs from a single
server. Therefore I am looking for capture card that can capture more
then one stream, but in the worst case I would buy 4 cards.
Unfortunately the DVI signal I want to cature is only digital DVI so
can't use cheap analog capture cards.
Here my wishlist of features:
- capturing of one or more digital DVI streams with a single card
- encoding/compression of the video on the capture card
(so I don't need a very fast computer)
- a very low framerate of 5 to 10 frames per second
- resolution around 1024x768
- full Linux support, of course
Any idea if something like this exists? Or how I could realise such a
setup?
Thanks a lot, Fabian
^ permalink raw reply
* Re: [PATCH] git-gui: delegate selection from gutter columns to text output
From: Bert Wesarg @ 2011-10-22 15:41 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87ehy63rvx.fsf@fox.patthoyts.tk>
On Sat, Oct 22, 2011 at 00:24, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
>>Selecting in the gutter columns of the blame view should make no sense,
>>so delegate any selection action in these columns to the text output
>>by selecting whole lines there.
>>
>>Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>>---
>> git-gui.sh | 20 ++++++++++++++++++++
>> lib/blame.tcl | 4 +++-
>> 2 files changed, 23 insertions(+), 1 deletions(-)
>>
>>diff --git a/git-gui.sh b/git-gui.sh
>>index 21033cb..cf5ed79 100755
>>--- a/git-gui.sh
>>+++ b/git-gui.sh
>>@@ -2077,6 +2077,26 @@ proc many2scrollbar {list mode sb top bottom} {
>> foreach w $list {$w $mode moveto $top}
>> }
>>
>>+proc delegate_sel_to {w from} {
>>+ set bind_list [list \
>>+ <Button-1> \
>>+ <B1-Motion> \
>>+ <Double-Button-1> \
>>+ <Triple-Button-1> \
>>+ <Shift-Button-1> \
>>+ <Double-Shift-Button-1> \
>>+ <Triple-Shift-Button-1> \
>>+ ]
>>+
>>+ foreach seq $bind_list {
>>+ set script [bind Text $seq]
>>+ set new_script [string map [list %W $w %x 0 word line] $script]
>>+ foreach f $from {
>>+ bind $f $seq "$new_script; break"
>>+ }
>>+ }
>>+}
>>+
>> proc incr_font_size {font {amt 1}} {
>> set sz [font configure $font -size]
>> incr sz $amt
>>diff --git a/lib/blame.tcl b/lib/blame.tcl
>>index 49eae19..9ab0da5 100644
>>--- a/lib/blame.tcl
>>+++ b/lib/blame.tcl
>>@@ -210,6 +210,8 @@ constructor new {i_commit i_path i_jump} {
>>
>> set w_columns [list $w_amov $w_asim $w_line $w_file]
>>
>>+ delegate_sel_to $w_file [list $w_amov $w_asim $w_line]
>>+
>> ${NS}::scrollbar $w.file_pane.out.sbx \
>> -orient h \
>> -command [list $w_file xview]
>>@@ -315,7 +317,7 @@ constructor new {i_commit i_path i_jump} {
>> $i conf -yscrollcommand \
>> "[list ::searchbar::scrolled $finder]
>> [list many2scrollbar $w_columns yview $w.file_pane.out.sby]"
>>- bind $i <Button-1> "
>>+ bind $i <Button-1> "+
>> [cb _hide_tooltip]
>> [cb _click $i @%x,%y]
>> focus $i
>
> The patch seems to be fine but I don't think I agree with the intention
> here. Currently clicking anywhere that is not marked as a link (blue
> underlined text) selects a commit and shows information in the lower
> pane. With this change, the left hand columns become inactive in regards
> to selecting a commit. I don't see why that is desirable.
Sorry, this was not intended. And I thought I took care for it with
the last hunk. I have a look at it again.
Bert
>
> --
> Pat Thoyts http://www.patthoyts.tk/
> PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
>
^ permalink raw reply
* [PATCH] kbuild: use xfwrite wrapper function to silence warnings
From: Peter Foley @ 2011-10-22 14:48 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Kbuild Mailing List, mmarek
Use the xfwrite wrapper function defined in lkc.h to check the return value of
fwrite and silence these warnings.
HOSTCC scripts/kconfig/zconf.tab.o
scripts/kconfig/zconf.tab.c: In function 'header_print_comment':
/usr/src/lto/scripts/kconfig/confdata.c:551:10: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
scripts/kconfig/zconf.tab.c: In function 'kconfig_print_comment':
/usr/src/lto/scripts/kconfig/confdata.c:467:10: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
Signed-off-by: Peter Foley <pefoley2@verizon.net>
---
scripts/kconfig/confdata.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 59b667c..f90c22f 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -464,7 +464,7 @@ kconfig_print_comment(FILE *fp, const char *value, void *arg)
fprintf(fp, "#");
if (l) {
fprintf(fp, " ");
- fwrite(p, l, 1, fp);
+ xfwrite(p, l, 1, fp);
p += l;
}
fprintf(fp, "\n");
@@ -548,7 +548,7 @@ header_print_comment(FILE *fp, const char *value, void *arg)
fprintf(fp, " *");
if (l) {
fprintf(fp, " ");
- fwrite(p, l, 1, fp);
+ xfwrite(p, l, 1, fp);
p += l;
}
fprintf(fp, "\n");
--
1.7.7
^ permalink raw reply related
* Re: [patch net-next V2] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-22 15:55 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, andy, tgraf,
ebiederm, mirqus, kaber, greearb, jesse, fbl, benjamin.poirier,
jzupka
In-Reply-To: <3128.1319221621@death>
Fri, Oct 21, 2011 at 08:27:01PM CEST, fubar@us.ibm.com wrote:
>Jiri Pirko <jpirko@redhat.com> wrote:
>
>>This patch introduces new network device called team. It supposes to be
>>very fast, simple, userspace-driven alternative to existing bonding
>>driver.
>>
>>Userspace library called libteam with couple of demo apps is available
>>here:
>>https://github.com/jpirko/libteam
>>Note it's still in its dipers atm.
>>
>>team<->libteam use generic netlink for communication. That and rtnl
>>suppose to be the only way to configure team device, no sysfs etc.
>>
>>Python binding basis for libteam was recently introduced (some need
>>still need to be done on it though). Daemon providing arpmon/miimon
>>active-backup functionality will be introduced shortly.
>>All what's necessary is already implemented in kernel team driver.
>>
>>Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>>v1->v2:
>> - modes are made as modules. Makes team more modular and
>> extendable.
>> - several commenters' nitpicks found on v1 were fixed
>> - several other bugs were fixed.
>> - note I ignored Eric's comment about roundrobin port selector
>> as Eric's way may be easily implemented as another mode (mode
>> "random") in future.
>>---
>
>[...]
>
>>+static int team_port_add(struct team *team, struct net_device *port_dev)
>>+{
>>+ struct net_device *dev = team->dev;
>>+ struct team_port *port;
>>+ char *portname = port_dev->name;
>>+ char tmp_addr[ETH_ALEN];
>>+ int err;
>>+
>>+ if (port_dev->flags & IFF_LOOPBACK ||
>>+ port_dev->type != ARPHRD_ETHER) {
>>+ netdev_err(dev, "Device %s is of an unsupported type\n",
>>+ portname);
>>+ return -EINVAL;
>>+ }
>>+
>>+ if (team_port_exists(port_dev)) {
>>+ netdev_err(dev, "Device %s is already a port "
>>+ "of a team device\n", portname);
>>+ return -EBUSY;
>>+ }
>>+
>>+ if (port_dev->flags & IFF_UP) {
>>+ netdev_err(dev, "Device %s is up. Set it down before adding it as a team port\n",
>>+ portname);
>>+ return -EBUSY;
>>+ }
>>+
>>+ port = kzalloc(sizeof(struct team_port), GFP_KERNEL);
>>+ if (!port)
>>+ return -ENOMEM;
>>+
>>+ port->dev = port_dev;
>>+ port->team = team;
>>+
>>+ port->orig.mtu = port_dev->mtu;
>>+ err = dev_set_mtu(port_dev, dev->mtu);
>>+ if (err) {
>>+ netdev_dbg(dev, "Error %d calling dev_set_mtu\n", err);
>>+ goto err_set_mtu;
>>+ }
>>+
>>+ memcpy(port->orig.dev_addr, port_dev->dev_addr, ETH_ALEN);
>>+ random_ether_addr(tmp_addr);
>>+ err = __set_port_mac(port_dev, tmp_addr);
>>+ if (err) {
>>+ netdev_dbg(dev, "Device %s mac addr set failed\n",
>>+ portname);
>>+ goto err_set_mac_rand;
>>+ }
>>+
>>+ err = dev_open(port_dev);
>>+ if (err) {
>>+ netdev_dbg(dev, "Device %s opening failed\n",
>>+ portname);
>>+ goto err_dev_open;
>>+ }
>>+
>>+ err = team_port_set_orig_mac(port);
>>+ if (err) {
>>+ netdev_dbg(dev, "Device %s mac addr set failed - Device does not support addr change when it's opened\n",
>>+ portname);
>>+ goto err_set_mac_opened;
>>+ }
>
> This will exclude a number of devices that bonding currently
>provides at least partial support for.
>
> Most of those are older 10 or 10/100 Ethernet drivers (anything
>that uses eth_mac_addr for its ndo_set_mac_address, I think; there look
>to be about 140 or so of those), but it also includes Infiniband (which
>is excluded explicitly elsewhere).
Team supports only ETH atm. I think it can be easily extended to support
Infiniband in future. But that's not priority now.
The "life mac change" check can be easily moved into port_enter mode
callback to let the mode decide. Then FOM active can be easily implemented
as another mode.
>
> Another small set of Ethernet devices (those that currently need
>bonding's fail_over_mac option) do permit setting the MAC while open,
>but will misbehave if multiple ports are set to the same MAC. The usual
>suspects here are ehea and qeth, which are partition-aware devices for
>IBM's pseries and zseries hardware, but there may be others I'm not
>familiar with.
Actually this (FOM2) is very close to the behaviour "activebackup" team
mode has now.
>
> If these will be permanent limitations of the team driver, then
>this should (eventually) be in the documentation.
>
> Also, from looking at the code, it's not obvious if nesting of
>teams is supported or not. I'm not seeing anything in the code that
>would prohibit adding a team device as a port to another team. If
>nesting of teams is undesirable, it should probably be explicitly tested
>for and disallowed.
Nesting is allowed.
>
>[...]
>
>>+static int __init team_module_init(void)
>>+{
>>+ int err;
>>+
>>+ register_netdevice_notifier(&team_notifier_block);
>>+
>>+ err = rtnl_link_register(&team_link_ops);
>>+ if (err)
>>+ goto err_rtln_reg;
>>+
>>+ err = team_nl_init();
>>+ if (err)
>>+ goto err_nl_init;
>>+
>>+ return 0;
>>+
>>+err_nl_init:
>>+ rtnl_link_unregister(&team_link_ops);
>>+
>>+err_rtln_reg:
>>+ unregister_netdevice_notifier(&team_notifier_block);
>
> Minor nit: I suspect you meant "err_rtnl_reg" here, and in the
>goto above.
Corrected.
Thanks Jay.
Jirka
>
> -J
>
>---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
^ permalink raw reply
* Re: Problem with log which are corrupted and need help with hitcount and FORWARD rules
From: Andrew Beverley @ 2011-10-22 16:01 UTC (permalink / raw)
To: Azerty Ytreza; +Cc: netfilter
In-Reply-To: <CACMGiwb3tXniJNt5vn6nBVqZjy8VUYWQkwg0GV=gVta5qzoaQw@mail.gmail.com>
On Sat, 2011-10-22 at 17:33 +0200, Azerty Ytreza wrote:
> **********************************************************************************************
> > Just mean gateway/firewall server that all the traffic passes through.
> >
> > No doesn't work ... The port is blocked when I try these rules (copy
> > of the INPUT rules) :
> >
> > iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
> > NEW -m recent --set
> > iptables -A FORWARD -i eth1 -p tcp -m tcp --dport 443 -m state --state
> > NEW -m recent --update --seconds 600 --hitcount 1 -j DROP
>
> You've got a hitcount of 1. Don't you mean 10 as you had in your first
> set of rules?
> Yes it's for test. The first time should work, the second request
> should be blocked for 600sec.
Hitcount matches when the number of packets is greater than or *equal*,
so defining a number of "1" will always match.
Also, hitcount refers to number of packets, so you'll need a rule in
there to only apply the DROP to NEW connections, otherwise you'll block
a successful connection as soon as that number of packets has been sent.
This website is quite good:
http://thiemonagel.de/2006/02/preventing-brute-force-attacks-using-iptables-recent-matching/
Although you'll have to change INPUT to FORWARD.
Andy
^ permalink raw reply
* Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understanding/modification
From: Pintu Kumar @ 2011-10-22 16:04 UTC (permalink / raw)
To: Kevin Wolf, Johannes Schindelin; +Cc: qemu-devel
In-Reply-To: <4E9FD811.6050002@redhat.com>
Hello Mr. Johannes, Kevin
I already did some work for scanning only top level directory in vvfat.
Using the following logic in read_directory()
if(parent_index >= 0 & (!dot & !dotdot))
{
free(buffer);
break;
}
Hope this is correct logic for skipping sub-directories content by
just scanning only dot and dotdot entries inside it.
But as per the recent analysis it was observed that there is some
problem in skipping sub-directory scanning itself.
Because when I issue "df" command on VVFAT partition I get
read_cluster errors during these sector location.
Mr. Johannes, can you clarify on this first.
Then we will look into the dynamic mapping part later.
Thank you very much.
Thanks, Regards,
Pintu
On Thu, Oct 20, 2011 at 1:43 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 19.10.2011 20:34, schrieb Pintu Kumar:
>> Dear Mr. Johannes,
>>
>> Thank you very much for your reply.
>>
>> So according to you implementing dynamic mapping logic after mounting
>> in VVFAT is possible.
>>
>> But from your following mail, I could not understand how to do that.
>>
>> Can you explain me with reference from the vvfat.c code.
>>
>> What should I do to scan only top level files/folders in read_directory?
>>
>> And what should I need to do in vvfatd_process_req (case : READ) to
>> create dynamic mapping on the fly before displaying the content on
>> guest OS.
>>
>> Right now I very this on my Linux PC it using "ls" command.
>>
>> Example:
>> If my vvfat mount path is /mnt/movifs and it contains one
>> sub-directory say "test1"
>> Then I use "ls -l /mnt/movifs/test1" in which case vvfatd_process_req
>> is invoked and then vvfat_read is invoked.
>>
>>
>> Please let me know.
>
> You asked in a second mail that you sent privately that I explain to you
> how to implement this, as you didn't fully understand what Johannes
> wrote. I'm going to add my reply here so that we don't have several
> separate mail threads. Actually, adding the mailing list wouldn't hurt
> either, but that's your decision.
>
> There's really one main thing that I would recommend you to finally do:
> Take a look at how FAT works. Completely independent of vvfat. And then
> think about how to implement something like this. And only then go back
> to vvfat and do it there. I won't do that for you, even if you double
> the length of the email thread.
>
>>> ---------- Forwarded message ----------
>>> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>>> Date: Wed, Oct 19, 2011 at 1:37 AM
>>> Subject: Re: [QEMU : VVFAT] vvfat.c - help required for
>>> understanding/modification
>>> To: Pintu Kumar <pintu.ping@gmail.com>
>>>
>>>
>>> Hi,
>>>
>>> On Sun, 16 Oct 2011, Pintu Kumar wrote:
>>>
>>>> In short, we wanted to implement partial scanning in the beginning and
>>>> dynamic mappings for VVFAT during runtime and after VVFAT is mounted.
>>>> That is, to scan only top level files and directories (skip
>>>> sub-directories content) during vvfat_prepare() and mount it.
>>>>
>>>> Later we a particular sub-directory is accessed by the guest OS, we
>>>> wanted to create its mapping on the fly.
>>>
>>> That sounds doable, since you can initialize the respective blocks in the
>>> FAT lazily, when they are accessed.
>
> I think it's possible in a very limited way. The nasty thing is that you
> don't really have the notion of directories when the guest accesses the
> file system. You have accesses to sectors that contain the FAT.
>
> Once the guest has read in a sector of the FAT, you must consider this
> sector final. You can't later allocate new clusters in this sector of
> the FAT because in general the guest OS will have cached the sector and
> won't reread it.
>
> So the real problem is to manage which clusters already have been read;
> which clusters you already referenced, but are still open for additions;
> and which files/subdirectories still need to be integrated somewhere.
> The guest can read the sectors of the FAT in any order, and it could
> read sectors that you haven't referenced yet at all (because, who reads
> single sectors?), which should add a bit to the fun.
>
>>>> I did some work on it but facing some problem. The sub-directory
>>>> contents are not visible after dynamic mapping and updating the FAT
>>>> content.
>>>>
>>>> I wanted to know your opinion if such kind of logic is possible to
>>>> implement in VVFAT.
>>>
>>> I think the basic problem is to know when to update the FAT content. As I
>>> alluded to above, I would do it thusly: Initialize the top-level directory
>>> and remember the blocks you want to use for the subdirectories. Whenever
>>> the corresponding blocks' contents are requested, initialize them, again
>>> ear-marking blocks for the subdirectories.
>>>
>>> But maybe I misunderstood?
>
> It really boils down to this question: Do we have enough space in the
> FAT for leaving most of it sparse? It looks like we're talking about a
> rather big directory tree, otherwise reading it in on startup wouldn't
> be a problem.
>
> And of course you're wasting precious disk space: If I understand the
> code right we only have 504 MB for the whole file system (should still
> be possible to increase a bit, but at some point you'll need FAT32). The
> available space will be reduced by same percentage as FAT entries stay
> unused.
>
> Kevin
>
^ permalink raw reply
* Re: NFS4 client blocked (kernel 3.0.7)
From: Dilip Daya @ 2011-10-22 16:00 UTC (permalink / raw)
To: linux-nfs@vger.kernel.org; +Cc: David Flynn
In-Reply-To: <20111022082838.GB32587@rd.bbc.co.uk>
See below...
0n Sat, 2011-10-22 at 08:28 +0000, David Flynn wrote:
> Dear all,
>
> When mounting a solaris NFS4 export on a v3.0.4 client, we've experienced
> processes becoming blocked. Any further attempt to access the mountpoint
> from another process also blocks. Other mountpoints are unaffected.
> I have not identified a test case to reproduce the behaviour.
>
> Any thoughts on the matter would be most welcome,
>
> Kind regards,
>
> ..david
>
> from /proc/mounts:
> home:/home/ /home nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.29.190.20,minorversion=0,local_lock=none,addr=172.29.120.140 0 0
>
> [105121.204200] INFO: task bash:4457 blocked for more than 120 seconds.
> [105121.247424] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [105121.299955] bash D ffffffff818050a0 0 4457 1 0x00000000
> [105121.347840] ffff8802954b5c28 0000000000000082 ffff8802954b5db8 0000000000012a40
> [105121.397793] ffff8802954b5fd8 0000000000012a40 ffff8802954b4000 0000000000012a40
> [105121.441724] 0000000000012a40 0000000000012a40 ffff8802954b5fd8 0000000000012a40
> [105121.441728] Call Trace:
> [105121.441740] [<ffffffff81110030>] ? __lock_page+0x70/0x70
> [105121.441744] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
> [105121.441746] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
> [105121.441749] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
> [105121.441751] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
> [105121.441756] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
> [105121.441759] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
> [105121.441761] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
> [105121.441786] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> [105121.441789] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
> [105121.441791] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
> [105121.441793] [<ffffffff8111050b>] filemap_fdatawait+0x2b/0x30
> [105121.441795] [<ffffffff81112124>] filemap_write_and_wait+0x44/0x60
> [105121.441803] [<ffffffffa0232805>] nfs_getattr+0x105/0x120 [nfs]
> [105121.441806] [<ffffffff81605e88>] ? do_page_fault+0x258/0x550
> [105121.441810] [<ffffffff81175b31>] vfs_getattr+0x51/0x120
> [105121.441812] [<ffffffff81175c70>] vfs_fstatat+0x70/0x90
> [105121.441814] [<ffffffff81175ccb>] vfs_stat+0x1b/0x20
> [105121.441816] [<ffffffff81175f14>] sys_newstat+0x24/0x40
> [105121.441820] [<ffffffff8101449a>] ? init_fpu+0x4a/0x150
> [105121.441822] [<ffffffff81602955>] ? page_fault+0x25/0x30
> [105121.441825] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
> [105121.441837] INFO: task bash:5612 blocked for more than 120 seconds.
> [105121.441838] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [105121.441840] bash D 0000000000000005 0 5612 1 0x00000000
> [105121.441843] ffff8801f25d5ca8 0000000000000086 ffff8800163e9b08 0000000000012a40
> [105121.441845] ffff8801f25d5fd8 0000000000012a40 ffff8801f25d4000 0000000000012a40
> [105121.441848] 0000000000012a40 0000000000012a40 ffff8801f25d5fd8 0000000000012a40
> [105121.441850] Call Trace:
> [105121.441853] [<ffffffff81110030>] ? __lock_page+0x70/0x70
> [105121.441855] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
> [105121.441857] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
> [105121.441859] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
> [105121.441861] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
> [105121.441863] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
> [105121.441866] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
> [105121.441868] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
> [105121.441876] [<ffffffffa023a7d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
> [105121.441878] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
> [105121.441880] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
> [105121.441882] [<ffffffff81111730>] filemap_write_and_wait_range+0x70/0x80
> [105121.441886] [<ffffffff8119cc6a>] vfs_fsync_range+0x5a/0x90
> [105121.441888] [<ffffffff8119cd0c>] vfs_fsync+0x1c/0x20
> [105121.441894] [<ffffffffa022ec74>] nfs_file_flush+0x54/0x80 [nfs]
> [105121.441898] [<ffffffff8116ee7f>] filp_close+0x3f/0x90
> [105121.441900] [<ffffffff8116f8a7>] sys_close+0xb7/0x120
> [105121.441902] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
> --
Same issue!
In my case I have NFS client & server both with Linux kernel
v3.0.7-stable.
Kernel: v3.0.7-stable (amd64)
# nfsstat -m
/opt/xorsyst/nfs_test from 192.168.1.53:/opt/xorsyst/nfs_test
Flags:
rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=192.168.1.52,minorversion=0,local_lock=none,addr=192.168.1.53
[48315.746955] nfs: server 192.168.1.53 not responding, still trying
[48315.748133] nfs: server 192.168.1.53 not responding, still trying
[48482.012303] INFO: task fblockio:15607 blocked for more than 120
seconds.
[48482.013506] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.014924] fblockio D ffff8800775bc420 0 15607 27608
0x00000000
[48482.016298] ffff88006fbd3c48 0000000000000046 ffff88006fbd3bf8
ffffffff81079174
[48482.017636] ffff88006fbd2010 ffff8800775bc140 00000000001d2f00
ffff88006fbd3fd8
[48482.018959] ffff88006fbd3fd8 00000000001d2f00 ffff8800807aa280
ffff8800775bc140
[48482.020370] Call Trace:
[48482.020901] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48482.022083] [<ffffffff8137c6ca>] ? __mutex_lock_common+0x239/0x390
[48482.023484] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.024905] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.026346] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.027523] [<ffffffff8137c6da>] __mutex_lock_common+0x249/0x390
[48482.028909] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.030328] [<ffffffff8100e7e9>] ? sched_clock+0x9/0xd
[48482.031498] [<ffffffff8137c91c>] mutex_lock_nested+0x3b/0x40
[48482.032794] [<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.034191] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48482.035409] [<ffffffffa04d2375>] nfs_file_write+0xda/0x172 [nfs]
[48482.036767] [<ffffffff81115e0b>] do_sync_write+0xc6/0x103
[48482.038010] [<ffffffff81077e18>] ? trace_hardirqs_off+0xd/0xf
[48482.039343] [<ffffffff811170b1>] ? fget_light+0xa3/0xc6
[48482.040552] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48482.041834] [<ffffffff81077e18>] ? trace_hardirqs_off+0xd/0xf
[48482.043153] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.044635] [<ffffffff811167c8>] vfs_write+0xac/0x108
[48482.045777] [<ffffffff811170c9>] ? fget_light+0xbb/0xc6
[48482.046968] [<ffffffff8111687c>] sys_pwrite64+0x58/0x77
[48482.048229] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.049577] 1 lock held by fblockio/15607:
[48482.050821] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at:
[<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.053225] INFO: task fblockio:10308 blocked for more than 120
seconds.
[48482.054715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.056469] fblockio D ffff88010b604d60 0 10308 27608
0x00000000
[48482.058130] ffff88008aeafc48 0000000000000046 ffff88008aeafbf8
ffffffff81079174
[48482.059717] ffff88008aeae010 ffff88010b604a80 00000000001d2f00
ffff88008aeaffd8
[48482.061368] ffff88008aeaffd8 00000000001d2f00 ffff880000184840
ffff88010b604a80
[48482.063002] Call Trace:
[48482.063541] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48482.064743] [<ffffffff8137c6ca>] ? __mutex_lock_common+0x239/0x390
[48482.066147] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.067557] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.068987] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.070152] [<ffffffff8137c6da>] __mutex_lock_common+0x249/0x390
[48482.071507] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.072934] [<ffffffff8137c91c>] mutex_lock_nested+0x3b/0x40
[48482.074224] [<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.075617] [<ffffffff8100f216>] ? native_sched_clock+0x2d/0x5f
[48482.076977] [<ffffffffa04d2375>] nfs_file_write+0xda/0x172 [nfs]
[48482.078353] [<ffffffff81046ee5>] ? finish_task_switch+0x82/0xef
[48482.079704] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48482.081059] [<ffffffff81115e0b>] do_sync_write+0xc6/0x103
[48482.082310] [<ffffffff81077e68>] ? lock_release_holdtime+0x2c/0xd7
[48482.083704] [<ffffffff8137ddfd>] ? _raw_spin_unlock_irq+0x2b/0x37
[48482.085090] [<ffffffff81046ea7>] ? finish_task_switch+0x44/0xef
[48482.086434] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.087886] [<ffffffff811167c8>] vfs_write+0xac/0x108
[48482.089054] [<ffffffff81117047>] ? fget_light+0x39/0xc6
[48482.090250] [<ffffffff811168e3>] sys_write+0x48/0x72
[48482.091424] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.092775] 1 lock held by fblockio/10308:
[48482.093700] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at:
[<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.096034] INFO: task fblockio:10349 blocked for more than 120
seconds.
[48482.097514] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.099196] fblockio D ffff880007de83e0 0 10349 27608
0x00000000
[48482.100796] ffff880004111c48 0000000000000046 ffff880004111bf8
ffffffff81079174
[48482.102476] ffff880004110010 ffff880007de8100 00000000001d2f00
ffff880004111fd8
[48482.104136] ffff880004111fd8 00000000001d2f00 ffff8800b1066a00
ffff880007de8100
[48482.105775] Call Trace:
[48482.106359] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48482.107551] [<ffffffff8137c6ca>] ? __mutex_lock_common+0x239/0x390
[48482.108961] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.110380] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.111792] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.112979] [<ffffffff8137c6da>] __mutex_lock_common+0x249/0x390
[48482.114360] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48482.115771] [<ffffffff8137c91c>] mutex_lock_nested+0x3b/0x40
[48482.117084] [<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.118485] [<ffffffff8100f216>] ? native_sched_clock+0x2d/0x5f
[48482.119847] [<ffffffffa04d2375>] nfs_file_write+0xda/0x172 [nfs]
[48482.121225] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48482.122516] [<ffffffff81115e0b>] do_sync_write+0xc6/0x103
[48482.123786] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.125263] [<ffffffff811167c8>] vfs_write+0xac/0x108
[48482.126443] [<ffffffff81117047>] ? fget_light+0x39/0xc6
[48482.127635] [<ffffffff811168e3>] sys_write+0x48/0x72
[48482.128784] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.130130] 1 lock held by fblockio/10349:
[48482.130999] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at:
[<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.133397] INFO: task fblockio:6007 blocked for more than 120
seconds.
[48482.134903] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.136659] fblockio D ffff880055e48660 0 6007 27608
0x00000000
[48482.138299] ffff8800129779f8 0000000000000046 0000000000000006
0000000000000002
[48482.139882] ffff880012976010 ffff880055e48380 00000000001d2f00
ffff880012977fd8
[48482.141603] ffff880012977fd8 00000000001d2f00 ffff8800b1066a00
ffff880055e48380
[48482.143207] Call Trace:
[48482.143726] [<ffffffff810cad31>] ? __lock_page+0x68/0x68
[48482.144947] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.146075] [<ffffffff8137bcff>] io_schedule+0x87/0xca
[48482.147298] [<ffffffff810cad3a>] sleep_on_page+0x9/0xd
[48482.148483] [<ffffffff8137c15c>] __wait_on_bit+0x43/0x76
[48482.149686] [<ffffffff810caf0d>] wait_on_page_bit+0x6d/0x74
[48482.150954] [<ffffffff810673db>] ? autoremove_wake_function
+0x34/0x34
[48482.152432] [<ffffffff810cc365>] grab_cache_page_write_begin
+0xa4/0xb6
[48482.153895] [<ffffffffa04d19b1>] nfs_write_begin+0xc3/0x1b8 [nfs]
[48482.155289] [<ffffffffa04d18d6>] ? nfs_write_end+0x11e/0x136 [nfs]
[48482.161747] [<ffffffff810c9f13>] ? iov_iter_copy_from_user_atomic
+0x7c/0xec
[48482.162963] [<ffffffff810ca219>] generic_file_buffered_write
+0x101/0x262
[48482.164222] [<ffffffff810cb7cc>] __generic_file_aio_write
+0x240/0x275
[48482.165397] [<ffffffff810cb861>] generic_file_aio_write+0x60/0xb7
[48482.166574] [<ffffffffa04d2375>] nfs_file_write+0xda/0x172 [nfs]
[48482.167666] [<ffffffff81115e0b>] do_sync_write+0xc6/0x103
[48482.168670] [<ffffffff81077e18>] ? trace_hardirqs_off+0xd/0xf
[48482.169715] [<ffffffff811170b1>] ? fget_light+0xa3/0xc6
[48482.170679] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48482.171720] [<ffffffff81077e18>] ? trace_hardirqs_off+0xd/0xf
[48482.182801] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.189220] [<ffffffff811167c8>] vfs_write+0xac/0x108
[48482.190105] [<ffffffff811170c9>] ? fget_light+0xbb/0xc6
[48482.191026] [<ffffffff8111687c>] sys_pwrite64+0x58/0x77
[48482.192018] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.193146] 1 lock held by fblockio/6007:
[48482.193883] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at:
[<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48482.195830] INFO: task fblockio:11226 blocked for more than 120
seconds.
[48482.197056] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.198472] fblockio D ffff8800043caa60 0 11226 27608
0x00000000
[48482.199900] ffff8800158d1b58 0000000000000046 ffff8800043ca780
ffff8800043cad88
[48482.201668] ffff8800158d0010 ffff8800043ca780 00000000001d2f00
ffff8800158d1fd8
[48482.213513] ffff8800158d1fd8 00000000001d2f00 ffff8800bf5ac6c0
ffff8800043ca780
[48482.215072] Call Trace:
[48482.215650] [<ffffffff810cad31>] ? __lock_page+0x68/0x68
[48482.216792] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.217857] [<ffffffff8137bcff>] io_schedule+0x87/0xca
[48482.218998] [<ffffffff810cad3a>] sleep_on_page+0x9/0xd
[48482.220216] [<ffffffff8137c05c>] __wait_on_bit_lock+0x41/0x8a
[48482.221477] [<ffffffff810cad2a>] __lock_page+0x61/0x68
[48482.222621] [<ffffffff810673db>] ? autoremove_wake_function
+0x34/0x34
[48482.224047] [<ffffffff810d5584>] lock_page+0x37/0x3b
[48482.225163] [<ffffffff810d5624>] invalidate_inode_pages2_range
+0x9c/0x2f3
[48482.226687] [<ffffffffa04f77f1>] ? rcu_read_lock_held+0x22/0x22
[nfs]
[48482.228098] [<ffffffff810d588a>] invalidate_inode_pages2+0xf/0x11
[48482.229454] [<ffffffffa04d4160>] nfs_revalidate_mapping+0x72/0xfc
[nfs]
[48482.245312] [<ffffffffa04d24a1>] nfs_file_read+0x94/0xd1 [nfs]
[48482.246327] [<ffffffff81115f0e>] do_sync_read+0xc6/0x103
[48482.247359] [<ffffffff81189dca>] ? fsnotify_perm+0x64/0x70
[48482.248366] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.249517] [<ffffffff811169b6>] vfs_read+0xa9/0x105
[48482.250442] [<ffffffff811170c9>] ? fget_light+0xbb/0xc6
[48482.251421] [<ffffffff81116a6a>] sys_pread64+0x58/0x77
[48482.252383] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.253680] no locks held by fblockio/11226.
[48482.254674] INFO: task fblockio:11240 blocked for more than 120
seconds.
[48482.256188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.257945] fblockio D ffff880081b027e0 0 11240 27608
0x00000000
[48482.259472] ffff8800806cdb58 0000000000000046 ffff880081b02500
ffff880081b02b08
[48482.261177] ffff8800806cc010 ffff880081b02500 00000000001d2f00
ffff8800806cdfd8
[48482.272504] ffff8800806cdfd8 00000000001d2f00 ffff88008285c7c0
ffff880081b02500
[48482.274188] Call Trace:
[48482.274696] [<ffffffff810cad31>] ? __lock_page+0x68/0x68
[48482.275942] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.277056] [<ffffffff8137bcff>] io_schedule+0x87/0xca
[48482.282992] [<ffffffff810cad3a>] sleep_on_page+0x9/0xd
[48482.283943] [<ffffffff8137c05c>] __wait_on_bit_lock+0x41/0x8a
[48482.285032] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48482.286042] [<ffffffff810cad2a>] __lock_page+0x61/0x68
[48482.286969] [<ffffffff810673db>] ? autoremove_wake_function
+0x34/0x34
[48482.288136] [<ffffffff810d5584>] lock_page+0x37/0x3b
[48482.289001] [<ffffffff810d5624>] invalidate_inode_pages2_range
+0x9c/0x2f3
[48482.290216] [<ffffffff810d588a>] invalidate_inode_pages2+0xf/0x11
[48482.291302] [<ffffffffa04d4160>] nfs_revalidate_mapping+0x72/0xfc
[nfs]
[48482.307024] [<ffffffffa04d24a1>] nfs_file_read+0x94/0xd1 [nfs]
[48482.308060] [<ffffffff81115f0e>] do_sync_read+0xc6/0x103
[48482.309025] [<ffffffff81189dca>] ? fsnotify_perm+0x64/0x70
[48482.310048] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.311279] [<ffffffff811169b6>] vfs_read+0xa9/0x105
[48482.312233] [<ffffffff811170c9>] ? fget_light+0xbb/0xc6
[48482.313182] [<ffffffff81116a6a>] sys_pread64+0x58/0x77
[48482.314129] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.315210] no locks held by fblockio/11240.
[48482.315978] INFO: task fblockio:11252 blocked for more than 120
seconds.
[48482.317221] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.318614] fblockio D ffff880106a408e0 0 11252 27608
0x00000000
[48482.320390] ffff880129c79b58 0000000000000046 ffff880106a40600
ffff880106a40c08
[48482.336509] ffff880129c78010 ffff880106a40600 00000000001d2f00
ffff880129c79fd8
[48482.337841] ffff880129c79fd8 00000000001d2f00 ffff880081282600
ffff880106a40600
[48482.339222] Call Trace:
[48482.339748] [<ffffffff810cad31>] ? __lock_page+0x68/0x68
[48482.340999] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.342105] [<ffffffff8137bcff>] io_schedule+0x87/0xca
[48482.343242] [<ffffffff810cad3a>] sleep_on_page+0x9/0xd
[48482.344449] [<ffffffff8137c05c>] __wait_on_bit_lock+0x41/0x8a
[48482.345739] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48482.347083] [<ffffffff810cad2a>] __lock_page+0x61/0x68
[48482.348290] [<ffffffff810673db>] ? autoremove_wake_function
+0x34/0x34
[48482.349743] [<ffffffff810d5584>] lock_page+0x37/0x3b
[48482.350877] [<ffffffff810d5624>] invalidate_inode_pages2_range
+0x9c/0x2f3
[48482.352434] [<ffffffff810d588a>] invalidate_inode_pages2+0xf/0x11
[48482.368385] [<ffffffffa04d4160>] nfs_revalidate_mapping+0x72/0xfc
[nfs]
[48482.369546] [<ffffffffa04d24a1>] nfs_file_read+0x94/0xd1 [nfs]
[48482.370601] [<ffffffff81115f0e>] do_sync_read+0xc6/0x103
[48482.371582] [<ffffffff81189dca>] ? fsnotify_perm+0x64/0x70
[48482.372609] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.373816] [<ffffffff811169b6>] vfs_read+0xa9/0x105
[48482.374734] [<ffffffff811170c9>] ? fget_light+0xbb/0xc6
[48482.375700] [<ffffffff81116a6a>] sys_pread64+0x58/0x77
[48482.376668] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.377737] no locks held by fblockio/11252.
[48482.378525] INFO: task fblockio:10681 blocked for more than 120
seconds.
[48482.379734] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48482.381160] fblockio D ffff880081b32de0 0 10681 27608
0x00000000
[48482.382629] ffff88012a6b9b58 0000000000000046 ffff880081b32b00
ffff880081b33108
[48482.398142] ffff88012a6b8010 ffff880081b32b00 00000000001d2f00
ffff88012a6b9fd8
[48482.399569] ffff88012a6b9fd8 00000000001d2f00 ffff8800814ce0c0
ffff880081b32b00
[48482.400918] Call Trace:
[48482.401467] [<ffffffff810cad31>] ? __lock_page+0x68/0x68
[48482.402681] [<ffffffff8137bc76>] schedule+0x55/0x57
[48482.403796] [<ffffffff8137bcff>] io_schedule+0x87/0xca
[48482.405002] [<ffffffff810cad3a>] sleep_on_page+0x9/0xd
[48482.406182] [<ffffffff8137c05c>] __wait_on_bit_lock+0x41/0x8a
[48482.407500] [<ffffffff810cad2a>] __lock_page+0x61/0x68
[48482.408754] [<ffffffff810673db>] ? autoremove_wake_function
+0x34/0x34
[48482.410205] [<ffffffff810d5584>] lock_page+0x37/0x3b
[48482.411340] [<ffffffff810d5624>] invalidate_inode_pages2_range
+0x9c/0x2f3
[48482.412901] [<ffffffff81104a9a>] ? virt_to_slab+0x9/0x3b
[48482.414095] [<ffffffff810d588a>] invalidate_inode_pages2+0xf/0x11
[48482.430079] [<ffffffffa04d4160>] nfs_revalidate_mapping+0x72/0xfc
[nfs]
[48482.435915] [<ffffffffa04d24a1>] nfs_file_read+0x94/0xd1 [nfs]
[48482.436960] [<ffffffff81115f0e>] do_sync_read+0xc6/0x103
[48482.437949] [<ffffffff81189dca>] ? fsnotify_perm+0x64/0x70
[48482.438956] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48482.440177] [<ffffffff811169b6>] vfs_read+0xa9/0x105
[48482.441076] [<ffffffff81117047>] ? fget_light+0x39/0xc6
[48482.442033] [<ffffffff81116ad1>] sys_read+0x48/0x72
[48482.442954] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48482.444102] no locks held by fblockio/10681.
[48602.444332] INFO: task fblockio:15607 blocked for more than 120
seconds.
[48602.445536] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48602.446957] fblockio D ffff8800775bc420 0 15607 27608
0x00000000
[48602.448439] ffff88006fbd3c48 0000000000000046 ffff88006fbd3bf8
ffffffff81079174
[48602.450107] ffff88006fbd2010 ffff8800775bc140 00000000001d2f00
ffff88006fbd3fd8
[48602.451786] ffff88006fbd3fd8 00000000001d2f00 ffff8800807aa280
ffff8800775bc140
[48602.453520] Call Trace:
[48602.454072] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48602.455272] [<ffffffff8137c6ca>] ? __mutex_lock_common+0x239/0x390
[48602.456703] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48602.458101] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48602.459517] [<ffffffff8137bc76>] schedule+0x55/0x57
[48602.460671] [<ffffffff8137c6da>] __mutex_lock_common+0x249/0x390
[48602.462015] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48602.463466] [<ffffffff8100e7e9>] ? sched_clock+0x9/0xd
[48602.464690] [<ffffffff8137c91c>] mutex_lock_nested+0x3b/0x40
[48602.465964] [<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48602.467355] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48602.468604] [<ffffffffa04d2375>] nfs_file_write+0xda/0x172 [nfs]
[48602.470235] [<ffffffff81115e0b>] do_sync_write+0xc6/0x103
[48602.471279] [<ffffffff81077e18>] ? trace_hardirqs_off+0xd/0xf
[48602.472398] [<ffffffff811170b1>] ? fget_light+0xa3/0xc6
[48602.473362] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48602.474395] [<ffffffff81077e18>] ? trace_hardirqs_off+0xd/0xf
[48602.475458] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48602.476671] [<ffffffff811167c8>] vfs_write+0xac/0x108
[48602.477578] [<ffffffff811170c9>] ? fget_light+0xbb/0xc6
[48602.478497] [<ffffffff8111687c>] sys_pwrite64+0x58/0x77
[48602.479462] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48602.480553] 1 lock held by fblockio/15607:
[48602.481341] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at:
[<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48602.483450] INFO: task fblockio:10308 blocked for more than 120
seconds.
[48602.484970] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[48602.486702] fblockio D ffff88010b604d60 0 10308 27608
0x00000000
[48602.488287] ffff88008aeafc48 0000000000000046 ffff88008aeafbf8
ffffffff81079174
[48602.489975] ffff88008aeae010 ffff88010b604a80 00000000001d2f00
ffff88008aeaffd8
[48602.491565] ffff88008aeaffd8 00000000001d2f00 ffff880000184840
ffff88010b604a80
[48602.493258] Call Trace:
[48602.493793] [<ffffffff81079174>] ? mark_lock+0x2d/0x235
[48602.494987] [<ffffffff8137c6ca>] ? __mutex_lock_common+0x239/0x390
[48602.496408] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48602.497825] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48602.499238] [<ffffffff8137bc76>] schedule+0x55/0x57
[48602.500384] [<ffffffff8137c6da>] __mutex_lock_common+0x249/0x390
[48602.501754] [<ffffffff810cb845>] ? generic_file_aio_write+0x44/0xb7
[48602.503183] [<ffffffff8137c91c>] mutex_lock_nested+0x3b/0x40
[48602.504515] [<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
[48602.505901] [<ffffffff8100f216>] ? native_sched_clock+0x2d/0x5f
[48602.507247] [<ffffffffa04d2375>] nfs_file_write+0xda/0x172 [nfs]
[48602.508626] [<ffffffff81046ee5>] ? finish_task_switch+0x82/0xef
[48602.509973] [<ffffffff8106ca9a>] ? sched_clock_cpu+0xc3/0xce
[48602.511257] [<ffffffff81115e0b>] do_sync_write+0xc6/0x103
[48602.512511] [<ffffffff81077e68>] ? lock_release_holdtime+0x2c/0xd7
[48602.513917] [<ffffffff8137ddfd>] ? _raw_spin_unlock_irq+0x2b/0x37
[48602.515344] [<ffffffff81046ea7>] ? finish_task_switch+0x44/0xef
[48602.516711] [<ffffffff81189e2d>] ? security_file_permission
+0x29/0x2e
[48602.518152] [<ffffffff811167c8>] vfs_write+0xac/0x108
[48602.519326] [<ffffffff81117047>] ? fget_light+0x39/0xc6
[48602.520530] [<ffffffff811168e3>] sys_write+0x48/0x72
[48602.521675] [<ffffffff81383a12>] system_call_fastpath+0x16/0x1b
[48602.523012] 1 lock held by fblockio/10308:
[48602.523962] #0: (&sb->s_type->i_mutex_key#15){+.+.+.}, at:
[<ffffffff810cb845>] generic_file_aio_write+0x44/0xb7
Thanking everyone in advance for any guidance or pointers to upstream
patches that I could try and provide feedback.
-DilipD.
^ permalink raw reply
* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Simon Glass @ 2011-10-22 16:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA27738.4060102@aribaud.net>
Hi Albert,
On Sat, Oct 22, 2011 at 12:56 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 22/10/2011 07:05, Simon Glass a ?crit :
>
>>>> Well I actually haven't moved it! It is just that previously it was
>>>> impossible to call cp15_init from anywhere later.
>>>
>>> It is moved, in that it belongs to low level init... of A9.
>>
>> OK, I see - you mean moved in order if not in source code file.
>
> Yes. In the code, though, it belongs to low-level init.
Arguably this could go in a library like arch/arm/cpu/armv7/lib/cache.S
>
>>>> What you say can be done, it would involve some assembler though and
>>>> would need to be another CONFIG option. Was trying to avoid adding new
>>>> assembler.
>>>
>>> Low level init is about assembler and, well, low level. :)
>>
>> Yes but it's yuck. Part of the clean-up is to remove most of the
>> assembler - really very little is needed.
>
> I don't think "yuck" is a valid reasoned argument against assembly language
> :) but I assume what you mainly mean is 'hard to understand and replaceable
> by easy to understand C code'. I agree to the first part, and to the second
> one for the general case, but not for the startup path where, precisely, we
> don't have a working C run-time and most of the understanding requires
> knowledge of hardware, not only general programming knowledge. Past that, C
I'm not arguing for the cache init stuff to move to C, just trying to
avoid any creeping growth of assembler when C can do it.
> is ok -- but then beware: some C++ guy could chime in and contend that C is
> "yuck" by your own standards. :)
The C++ guy who finds himself in U-Boot is probably lost :-)
>
>>> But I don't see why there should be another CONFIG option. IIUC, you
>>> should
>>> be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level
>>> init
>>> code under it, you would do the equivalent of a switch, with one branch
>>> for
>>> AVM (and DDR init etc) and one branch for A9 (with cp15 init etc).
>>
>> Yes I can, but I need to be able to call cp15_init. And I can't do
>> that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is
>> compiled out! So I need to move that cp15_init code outside the
>> CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do,
>> honest!
>
> I understand, and I think the approach here is wrong, because you *do* want
> low-level init in the A9 case, and thus you should not have
> CONFIG_SKIP_LOWLEVEL_INIT set. But you also need the AVP low-level init to
> be empty, and the AVP and A9 must follow the same startup path. And all this
> it not necessarily required for all armv7 platforms, but some of them will
> want lowlevel init, and some not. Considering all this...
>
> For now, I would opt for a CONFIG_ARCH_GENERIC_LOWLEVEL_INIT option which
> start.S would use to compile out the low level init code definition (like
> CONFIG_SKIP_LOWLEVEL_INIT does) but not the the calls to it (UNline
> CONFIG_SKIP_LOWLEVEL_INIT does). Then you could provide a SoC-specific
> version of lowlevel_init.
If I understand you correctly, this is the opposite of what I want. It
is basically what we have now.
All ARMv7 chips are going to turn off MMU, caches, flush TLBs, and the
like - this is an architecture feature, not an SOC one. We have
conflated ARM arch init with SOC init as you say, but the solution is
not to force the SOC to copy code from start.S just so that it can do
ARM arch init later.
And I'd argue for LOWLEVEL_INIT being about setting up the memory so
we can run code, and in particular relocate it later. The cp15_init
stuff should arguably be in arch_cpu_init() (or perhaps a new
arch_init()) as the first thing called from board_init_f() in my view.
So how about I create a patch to move the cp15_init() code into
arch/arm/cpu/armv7/lib/lowlevel.S or similar so I can call it later?
>
> In the longer term, I would be more in favor of a weak definition system
> with hierarchical ARCH, ISA, SoC, board priority order (yes, I am kind of
> fond of it) for lowlevel init -- but that will require looking into asm weak
> symbol handling and may require splitting of the assembly code function by
> function.
I think you are trying to avoid the
#ifdef CONFIG_ARCH_CPU_INIT
arch_cpu_init,
#endif
#ifdef ...
some_other_thing
#endif
in the board_init_f() function table. Yes I agree it would tidy things
up, although I wonder if Graeme's initcall thing isn't better again.
It has the same confusion level coefficient (only the linker decides
what code is included) with a bit more flexibility. Then each arch /
board / cpu / soc / squirrel can decide on its own init and put it in
its own file. C only please :-)
Regards,
Simon
>
>> Regards,
>> Simon
>
> Amicalement,
> --
> Albert.
>
^ 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.