headers
Benjamin Herrenschmidt | 1 Apr 2008 01:12

Re: [PATCH] evdev: Release eventual input device grabs when getting disconnected


> I do agree that this might want reverting, unless there is some rally good 
> reason for it. People may have pefectly valid reasons to expect topology 
> and reachability to remain valid - it's certainly what we guarantee in the 
> VFS code for similar rules (ie the parent of a dentry is only free'd after 
> all children have gone away).
> 
> Greg, is it possible to get the old lifetime rules back wrt his? They seem 
> valid and sane..

Looks like we are seeing something similar with suspend, I just got this
oops log. I think what happens is that appletouch suspend causes it to
disconnect and then X console switches or closes the evdev, whatever,
kaboom ...

sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
usbcore: deregistering interface driver appletouch
input: appletouch disconnected
PM: Syncing filesystems ... done.
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
Modules linked in: sg sd_mod binfmt_misc appletalk psnap llc hci_usb radeon drm rfcomm l2cap bluetooth
cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative xt_tcpudp
nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables fuse i2c_dev
therm_adt746x sr_mod sbp2 apm_emu apm_emulation arc4 ecb snd_aoa_codec_tas snd_aoa_fabric_layout
snd_aoa b43 mac80211 joydev pcmcia cfg80211 rng_core ohci1394 snd_aoa_i2sbus ieee1394 snd_pcm
snd_page_alloc snd_seq_midi snd_rawmidi pmac_zilog serial_core snd_seq_midi_event snd_seq
snd_timer snd_seq_device snd soundcore snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core
ssb uninorth_agp agpgart [last unloaded: appletouch]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rafael J. Wysocki | 1 Apr 2008 01:14
Picon
Gravatar

Re: The never ending BEEEEP/__smp_call_function_mask with 2.6.25-rc7

On Tuesday, 1 of April 2008, Chr wrote:
> On Sunday 30 March 2008 23:36:40 Thomas Gleixner wrote:
> > On Sun, 30 Mar 2008, Chr wrote:
> >
> > You mentioned that you have tons of other logs. Can you please
> > upload those to some place? If you don't have a possiblity, please
> > contact me private and I'll provide you one.
> >
> Ahhm it happend again (well, actually it's the fifth time today, but this time
> I _hopefully_ found something)
> 
> I made a new log: (check out bugzilla)
> http://bugzilla.kernel.org/show_bug.cgi?id=10369
> 
> (direct link)
> http://bugzilla.kernel.org/attachment.cgi?id=15542
> 
> so, this log was made from a _working_ machine over the serial
> console... I put some _real_ "date" marks here and there... 
> to explain a bit, how the time STALLS... (well, it seems like
> it goes a bit backward and forward and backwards again...  it loops?!
> whatever..!??!?!!)
> 
> just take a look at the jiffies (grep for them... it takes "minutes"
> until jiffies+1 comes)
> 
> Maybe there's a "signed" problem somewhere in the timekeeping
> code? Or does 2.6.25-rcX have a general problem with NTP-daemons
> like chrony?
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Chinner | 1 Apr 2008 01:21
Picon
Favicon

Re: getting uninterruptible sleep processes after upgrade from 2.6.20.20 to 2.6.24.2

On Sun, Feb 24, 2008 at 11:06:49AM +0100, Jiri Slaby wrote:
> Ccing xfs team
> 
> On 02/21/2008 02:37 PM, Stefan Priebe - allied internet ag wrote:
> >Hello!
> >
> >I'm using XFS. dmesg -s32000 does not help - no more output. In messages 
> >there is also no relevant output. Other than what I've posted here:
> >http://lkml.org/lkml/2008/2/21/76
> 
> http://lkml.org/lkml/2008/2/21/86
> 
> Some kind of borkage in readdir, probably either in xfs or vfs?

Fixed in 2.6.24.3.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=450790a2c51e6d9d47ed30dbdcf486656b8e186f

Please upgrade.

Cheers,

Dave.
--

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
Permalink | Reply | 0 comments |
headers
Mikulas Patocka | 1 Apr 2008 01:22
Picon

[PATCH] plip: replace spin_lock_irq with spin_lock_irqsave in irq context

Hi

Plip uses spin_lock_irq/spin_unlock_irq in its IRQ handler (called from 
parport IRQ handler), the latter enables interrupts without parport 
subsystem IRQ handler expecting it.

The bug can be seen if you compile kernel with lock dependency checking 
and use plip --- it produces a warning.

This patch changes it to spin_lock_irqsave/spin_lock_irqrestore, so that 
it doesn't enable interrupts when already disabled.

Mikulas

--- linux-2.6.24.4/drivers/net/plip.c_	2008-03-31 23:47:27.000000000 +0200
+++ linux-2.6.24.4/drivers/net/plip.c	2008-03-31 23:48:06.000000000 +0200
 <at>  <at>  -903,17 +903,18  <at>  <at>  plip_interrupt(void *dev_id)
 	struct net_local *nl;
 	struct plip_local *rcv;
 	unsigned char c0;
+	unsigned long flags;

 	nl = netdev_priv(dev);
 	rcv = &nl->rcv_data;

-	spin_lock_irq (&nl->lock);
+	spin_lock_irqsave (&nl->lock, flags);

 	c0 = read_status(dev);
 	if ((c0 & 0xf8) != 0xc0) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Chiang | 1 Apr 2008 01:25
Picon
Favicon

Re: [ANNOUNCE] Btrfs v0.13

* Alex Chiang <achiang <at> hp.com>:
> * David Miller <davem <at> davemloft.net>:
> > From: Alex Chiang <achiang <at> hp.com>
> > Date: Mon, 31 Mar 2008 14:26:33 -0600
> > 
> > > I've gotten as far as successfully creating a btrfs filesystem
> > > (at least that's what btrfsck tells me), but haven't been able to
> > > mount it yet, probably because of the sector size issue.
> > 
> > You should be able to make a filesystem with a sector
> > size >= PAGE_SIZE and it should work just fine.  Please
> > give it a try.
> 
> Hrm, I'm having issues still. First, here's a patch for
> mkfs.btrfs to allow the user to pass in a different sector size.

Whoops, whitespace was screwed up on that patch. Here's try #2.

/ac

From: Alex Chiang <achiang <at> hp.com>
Subject: [PATCH] Teach mkfs.btrfs about configurable sectorsizes

Currently, btrfs assumes PAGE_SIZE <= sectorsize, and sectorsize
is hardcoded to 4K in mkfs.btrfs.

Give mkfs.btrfs a new command line option to specify a different
sector size. The syntax follows mke2fs's -E extended-options syntax,
and the code is taken from mke2fs.
---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chr | 1 Apr 2008 01:30
Picon

Re: The never ending BEEEEP/__smp_call_function_mask with 2.6.25-rc7

On Tuesday 01 April 2008 01:14:24 Rafael J. Wysocki wrote:
> On Tuesday, 1 of April 2008, Chr wrote:
>
> Have you posted the .config already?
Done!

BTW:
[ 5074.308547]   .jiffies                       : 4296102117
[ 5074.308547]   .jiffies                       : 4296102117
[ 5105.659185]   .idle_jiffies   : 4296102113
[ 5105.659185]   .last_jiffies   : 4296102117
[ 5105.659185]   .next_jiffies   : 4296102118
[ 5105.659185] jiffies: 4296102117
[ 5105.659185]   .idle_jiffies   : 4296102114
[ 5105.659185]   .last_jiffies   : 4296102113
[ 5105.659185]   .next_jiffies   : 4296102116
[ 5105.659185] jiffies: 4296102117
[ 5044.543918]   .jiffies                       : 4296102117
[ 5044.640998]   .jiffies                       : 4296102117
[ 4979.215327]   .idle_jiffies   : 4296102113
[ 4979.229471]   .last_jiffies   : 4296102117
[ 4979.231334]   .next_jiffies   : 4296102118
[ 4979.235415] jiffies: 4296102117
[ 4979.298216]   .idle_jiffies   : 4296102114
[ 4979.312360]   .last_jiffies   : 4296102113
[ 4979.314223]   .next_jiffies   : 4296102116
[ 4979.318303] jiffies: 4296102117
[ 5040.749212]   .idle_jiffies   : 4296102113
[ 5040.763356]   .last_jiffies   : 4296102117
[ 5040.765219]   .next_jiffies   : 4296102118
(Continue reading)

Permalink | Reply | 3 comments |
headers
KOSAKI Motohiro | 1 Apr 2008 01:28
Favicon

Re: [PATCH] hugetlb: vmstat events for huge page allocations

Hi

> Allocating huge pages directly from the buddy allocator is not guaranteed
> to succeed.  Success depends on several factors (such as the amount of
> physical memory available and the level of fragmentation).  With the
> addition of dynamic hugetlb pool resizing, allocations can occur much more
> frequently.  For these reasons it is desirable to keep track of huge page
> allocation successes and failures.
> 
> Add two new vmstat entries to track huge page allocations that succeed and
> fail.  The presence of the two entries is contingent upon
> CONFIG_HUGETLB_PAGE being enabled.

In generaly, I like this patch.

Have you seen Andi Kleen's "GB pages hugetlb support" series?
it contain multiple size hugepage support.
if it is merged, Is your patch caused any effect?
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Apr 2008 01:51
Gravatar

Re: [PATCH] evdev: Release eventual input device grabs when getting disconnected

On Tue, Apr 01, 2008 at 10:12:44AM +1100, Benjamin Herrenschmidt wrote:
> 
> > I do agree that this might want reverting, unless there is some rally good 
> > reason for it. People may have pefectly valid reasons to expect topology 
> > and reachability to remain valid - it's certainly what we guarantee in the 
> > VFS code for similar rules (ie the parent of a dentry is only free'd after 
> > all children have gone away).
> > 
> > Greg, is it possible to get the old lifetime rules back wrt his? They seem 
> > valid and sane..
> 
> Looks like we are seeing something similar with suspend, I just got this
> oops log. I think what happens is that appletouch suspend causes it to
> disconnect and then X console switches or closes the evdev, whatever,
> kaboom ...
> 
> sd 0:0:0:0: [sda] Synchronizing SCSI cache
> sd 0:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
> usbcore: deregistering interface driver appletouch
> input: appletouch disconnected
> PM: Syncing filesystems ... done.
> Oops: Kernel access of bad area, sig: 11 [#1]
> PowerMac
> Modules linked in: sg sd_mod binfmt_misc appletalk psnap llc hci_usb radeon drm rfcomm l2cap bluetooth
cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative xt_tcpudp
nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables fuse i2c_dev
therm_adt746x sr_mod sbp2 apm_emu apm_emulation arc4 ecb snd_aoa_codec_tas snd_aoa_fabric_layout
snd_aoa b43 mac80211 joydev pcmcia cfg80211 rng_core ohci1394 snd_aoa_i2sbus ieee1394 snd_pcm
snd_page_alloc snd_seq_midi snd_rawmidi pmac_zilog serial_core snd_seq_midi_event snd_seq
snd_timer snd_seq_device snd soundcore snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Morton | 1 Apr 2008 01:57

Re: [PATCH 3/4] Char: ip2, fix sparse warnings

On Fri, 28 Mar 2008 22:18:43 +0100
Jiri Slaby <jirislaby <at> gmail.com> wrote:

> Unlock two grabbed locks on some paths.
> 
> Signed-off-by: Jiri Slaby <jirislaby <at> gmail.com>
> ---
>  drivers/char/ip2/i2lib.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/char/ip2/i2lib.c b/drivers/char/ip2/i2lib.c
> index 618f5fe..1d5388c 100644
> --- a/drivers/char/ip2/i2lib.c
> +++ b/drivers/char/ip2/i2lib.c
>  <at>  <at>  -643,12 +643,12  <at>  <at>  i2QueueCommands(int type, i2ChanStrPtr pCh, int timeout, int nCommands,
>  				// Normal Expected path - We still hold LOCK
>  				break; /* from for()- Enough room: goto proceed */
>  			}
> -		}
> -
> -		ip2trace (CHANN, ITRC_QUEUE, 3, 1, totalsize );
> +			ip2trace(CHANN, ITRC_QUEUE, 3, 1, totalsize);
> +			write_unlock_irqrestore(lock_var_p, flags);
> +		} else
> +			ip2trace(CHANN, ITRC_QUEUE, 3, 1, totalsize);
>  
>  		// Prepare to wait for buffers to empty
> -		write_unlock_irqrestore(lock_var_p, flags);
>  		serviceOutgoingFifo(pB);	// Dump what we got
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jiri Kosina | 1 Apr 2008 02:08
Picon

spinlocks -- why are releases inlined and acquires are not?

Hi,

include/linux/spinlock.h shows:

	#define spin_lock_irq(lock)             _spin_lock_irq(lock)

unconditionally, i.e. irrespectible of config options, we always (on SMP) 
call kernel/spinlock.c:_spin_lock_irq(), which is even not inlined.

Contrary to that, unlocks are written as one would expect, i.e:

	#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT) || \
        	!defined(CONFIG_SMP)
	# define spin_unlock_irq(lock)          _spin_unlock_irq(lock)
	#else
	# define spin_unlock_irq(lock)                  \
	do {                                            \
        	__raw_spin_unlock(&(lock)->raw_lock);   \
	        __release(lock);                        \
	        local_irq_enable();                     \
	} while (0)

and __raw_spin_unlock() is of course properly inlined.

What is the reason for this asymetry? Shouldn't the acquiring functions be 
implemented in the very same way? Or at least, shouldn't all the 
__lockfunc functions be inlined?

Thanks,
(Continue reading)

Permalink | Reply | 8 comments |

Gmane