twitter: linux.kernel - 26 new messages in 15 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* HDA Intel Audio hang on boot - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
* Hyperthreading on Core i7s: To use or not to use? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/185addf08bbc650e?hl=en
* OOM-Killer kills too much with 2.6.32.2 - 5 messages, 4 authors
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
* radeon kms - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/da301c22e0b6fda3?hl=en
* block: fix bio_add_page for non trivial merge_bvec_fn case - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/10f0ec95bfdc56f7?hl=en
* request for assistance: accessing ttys from kernel space - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/cd06029f40862317?hl=en
* mm/readahead.c: update the LRU positions of in-core pages, too - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/c3e8affbeb80ebe0?hl=en
* usb: otg: add notifier support - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* linux-next: add utrace tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
* betra yal predi ctabl e satur able aleat oric varia blity - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/687424b83ca486f9?hl=en
* System panic under load with clockevents_program_event - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/8dc02ff411331726?hl=en
* PM / i915: Skip kernel VT switch during suspend/resume if KMS is used - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e208566420ffb479?hl=en
* clocksource: Prevent potential kgdb dead lock - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* PROBLEM: freeze on ppp connection (using an usb "key" modem) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/2da2ca2c0a18eb99?hl=en
* fs: re-order super_block to remove 16 bytes of padding on 64bit builds - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/6ca13e5299dd1f6b?hl=en

==============================================================================
TOPIC: HDA Intel Audio hang on boot
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 5:20 am
From: Sid Boyce

On 26/01/10 12:51, Rafael J. Wysocki wrote:
> On Tuesday 26 January 2010, Sid Boyce wrote:
>> On 26/01/10 06:58, Takashi Iwai wrote:
> ...
>>> And... is this report for 2.6.32 or for 2.6.33?
>>> If it's with 2.6.32, enable_msi=1 may help instead.
>>>
>>>
>> The motherboard giving the problem is the Asus M2N32-SLI deluxe.
>> 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio
>> (rev a2)
>>
>> No such problem with the Asus CROSSHAIR II FORMULA motherboard which
>> also has the
>> 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S
>> High Definition Audio (rev a1)
>>
>> For any kernel >2.6.32-git1 it hangs, i.e 2.6.32-git2 to 2.6.33-rc5.
>> Disabling the sound chip in the BIOS, they all boot.
>> tindog:/etc/modprobe.d # uname -r
>> 2.6.32-git1-smp
>> tindog:/etc/modprobe.d # l /dev/dsp*
>> crw-rw-rw- 1 root audio 14, 3 Jan 26 11:46 /dev/dsp
>> crw-rw-rw- 1 root audio 14, 35 Jan 26 11:46 /dev/dsp2
>
> Is your adapter build as a module or is it compiled directly into the kernel?
>
> Rafael
>
As a module in 2.6.33-git1 and always for all kernels.
# lsmod|grep snd
snd_pcm_oss 40102 0
snd_mixer_oss 14822 1 snd_pcm_oss
snd_seq 52843 0
snd_hda_codec_analog 73538 1
snd_hda_intel 23660 0
snd_hda_codec 75402 2 snd_hda_codec_analog,snd_hda_intel
snd_usb_audio 85288 0
snd_usb_lib 16705 1 snd_usb_audio
snd_rawmidi 21568 1 snd_usb_lib
snd_pcm 81892 4
snd_pcm_oss,snd_hda_intel,snd_hda_codec,snd_usb_audio
snd_seq_device 6514 2 snd_seq,snd_rawmidi
snd_hwdep 6346 2 snd_hda_codec,snd_usb_audio
snd_timer 20760 2 snd_seq,snd_pcm
snd 66395 13
snd_pcm_oss,snd_mixer_oss,snd_seq,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_usb_lib,snd_rawmidi,snd_pcm,snd_seq_device,snd_hwdep,snd_timer
snd_page_alloc 7873 2 snd_hda_intel,snd_pcm
soundcore 7147 1 snd
usbcore 146206 6
rtl8187,snd_usb_audio,snd_usb_lib,usbhid,ohci_hcd,ehci_hcd
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 5:50 am
From: Takashi Iwai

At Tue, 26 Jan 2010 13:44:23 +0000,
Sid Boyce wrote:
>
> On 26/01/10 12:55, Takashi Iwai wrote:
> > At Tue, 26 Jan 2010 12:02:44 +0000,
> > Sid Boyce wrote:
> >>
> >> On 26/01/10 06:58, Takashi Iwai wrote:
> >>> At Tue, 26 Jan 2010 07:40:03 +0100,
> >>> I wrote:
> >>>>
> >>>> At Tue, 26 Jan 2010 00:59:15 +0000,
> >>>> Sid Boyce wrote:
> >>>>>
> >>>>> On 25/01/10 21:55, Takashi Iwai wrote:
> >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100,
> >>>>>> I wrote:
> >>>>>>>
> >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100,
> >>>>>>> Rafael J. Wysocki wrote:
> >>>>>>>>
> >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote:
> >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote:
> >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
> >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
> >>>>>>>>> is not disabled in the BIOS.
> >>>>>>>>
> >>>>>>>> I guess we should let Takashi know.
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>>>>> tindog:~ # uname -r
> >>>>>>>>>> 2.6.33-rc4-smp
> >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:-
> >>>>>>>>>> oss.card_id = 'HDA NVidia'
> >>>>>>>>>> oss.card_id = 'HDA NVidia'
> >>>>>>>>>> oss.card_id = 'HDA NVidia'
> >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
> >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device'
> >>>>>>>>>> alsa.card_id = 'HDA NVidia'
> >>>>>>>>>> info.product = 'HDA NVidia Sound Card'
> >>>>>>>>>> sound.card_id = 'HDA NVidia'
> >>>>>>>>>> info.linux.driver = 'HDA Intel'
> >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
> >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> >>>>>>>>>> HDA Intel: module = snd_hda_intel
> >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
> >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> >>>>>>>>>> HDA Intel: module = snd_hda_intel
> >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
> >>>>>>>>>> HDA Intel: module = snd_hda_intel
> >>>>>>>>>> E: DRIVER=HDA Intel
> >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
> >>>>>>>>>> low) -> IRQ 22
> >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
> >>>>>>>>>> Driver: "HDA Intel"
> >>>>>>>
> >>>>>>> What I'd try first is to pass enable_msi=0 option.
> >>>>>>
> >>>>>> Just to be sure -- it's an option for snd-hda-intel module.
> >>>>>>
> >>>>>>
> >>>>>> Takashi
> >>>>>>
> >>>>>
> >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
> >>>>> line,
> >>>
> >>> Oh, I overlooked this text. Of course, this can't work :)
> >>>
> >>> "modprobe..." isn't for the kernel command line but for modprobe
> >>> configs, usually specified in /etc/modprobe.d/* file.
> >>>
> >> I had already tried that... it locks up at the same point also with
> >> "enable_msi=1".
> >> tindog:/etc/modprobe.d # less 50-sound.conf
> >>
> >> options snd slots=snd-hda-intel,enable_msi=0
> >
> > This is the option for module snd, not snd-hda-intel.
> >
> >
> > Takashi
> >
> options snd,enable_msi=0 slots=snd-hda-intel

It's a line for module "snd,enable_msi=0", which is likely invalid :)

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Jan 26 2010 5:50 am
From: Sid Boyce

On 26/01/10 12:55, Takashi Iwai wrote:
> At Tue, 26 Jan 2010 12:02:44 +0000,
> Sid Boyce wrote:
>>
>> On 26/01/10 06:58, Takashi Iwai wrote:
>>> At Tue, 26 Jan 2010 07:40:03 +0100,
>>> I wrote:
>>>>
>>>> At Tue, 26 Jan 2010 00:59:15 +0000,
>>>> Sid Boyce wrote:
>>>>>
>>>>> On 25/01/10 21:55, Takashi Iwai wrote:
>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100,
>>>>>> I wrote:
>>>>>>>
>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100,
>>>>>>> Rafael J. Wysocki wrote:
>>>>>>>>
>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote:
>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote:
>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
>>>>>>>>> is not disabled in the BIOS.
>>>>>>>>
>>>>>>>> I guess we should let Takashi know.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>>>> tindog:~ # uname -r
>>>>>>>>>> 2.6.33-rc4-smp
>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:-
>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device'
>>>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>>>> info.product = 'HDA NVidia Sound Card'
>>>>>>>>>> sound.card_id = 'HDA NVidia'
>>>>>>>>>> info.linux.driver = 'HDA Intel'
>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>>>> E: DRIVER=HDA Intel
>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
>>>>>>>>>> low) -> IRQ 22
>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
>>>>>>>>>> Driver: "HDA Intel"
>>>>>>>
>>>>>>> What I'd try first is to pass enable_msi=0 option.
>>>>>>
>>>>>> Just to be sure -- it's an option for snd-hda-intel module.
>>>>>>
>>>>>>
>>>>>> Takashi
>>>>>>
>>>>>
>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
>>>>> line,
>>>
>>> Oh, I overlooked this text. Of course, this can't work :)
>>>
>>> "modprobe..." isn't for the kernel command line but for modprobe
>>> configs, usually specified in /etc/modprobe.d/* file.
>>>
>> I had already tried that... it locks up at the same point also with
>> "enable_msi=1".
>> tindog:/etc/modprobe.d # less 50-sound.conf
>>
>> options snd slots=snd-hda-intel,enable_msi=0
>
> This is the option for module snd, not snd-hda-intel.
>
>
> Takashi
>
options snd,enable_msi=0 slots=snd-hda-intel
# 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio
alias snd-card-0 snd-hda-intel

enable_msi=0 or 1, it still hangs.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

==============================================================================
TOPIC: Hyperthreading on Core i7s: To use or not to use?
http://groups.google.com/group/linux.kernel/t/185addf08bbc650e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 5:20 am
From: peng huang

Hello,

I have been done some benchmark things on the processors with HT,
if you run lots of processes/threads that more than the physical
cores,may be you should enable the HT to get more benefits.
#unless your processes cause some cache competitions.

I will send you some test data later.

-huang

2010-01-26 (火) の 10:56 +0000 に Daniel J Blueman さんは書きました:
> On Jan 26, 10:10 am, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> > Hello,
> >
> > Should the 'correct' kernel [CPU] configuration for a core i7 860/870..?
> >
> > - Multi-core support
> > - Cores: 8
> > - SMT: Enabled/ON
> >
> > From CONFIG_SCHED_SMT:
> >
> > . SMT scheduler support improves the CPU scheduler's decision making .
> > . when dealing with Intel Pentium 4 chips with HyperThreading at a .
> > . cost of slightly increased overhead in some places. If unsure say .
> > . N here. .
> >
> > Does this also 'help' and/or 'apply' as much when dealing with Core i7s?
> >
> > --
> >
> > Quick little benchmark (pbzip2 -9 linux kernel source), the benchmark is
> > really within the noise (8 on/off)
> > - Multicore(8)/HT(Off) = 73.72user 0.33system 0:09.50elapsed 779%CPU (0avgtext+0avgdata 458528maxresident
> > - Multicore(8)/HT(On) = 74.28user 0.40system 0:09.67elapsed 772%CPU (0avgtext+0avgdata 428304maxresident
> > - Multicore(4)/HT(On) = 68.76user 0.30system 0:17.44elapsed 396%CPU (0avgtext+0avgdata 213616maxresident)k
> >
> > --
> >
> > Has anyone done any in-depth benchmarking for the core i7s that have multiple
> > cores and HT disabled/enabled?
>
> With my Dell Studio 15 (model 1557) laptop, there is no option to
> disable HT in the current BIOS, so booting with maxcpus=4 (since the
> kernel enumerates non-sibling cores first) gave me a 5-15% speedup on
> some large image processing (convolution, FFTs, conversion) on all
> available cores, presumably due to better cache efficiency.
>
> Booting with maxcpus=4 prevents any of the cores sitting in C6, needed
> for turbo-boost and a lower thermal profile, though I did find
> scheduling latency and responsiveness better under load booting with
> maxcpus=4, so favour this when plugged in.
>
> Clearly, having the BIOS option allows benefit to certain applications
> - Dell should give their users the choice!
>
> Perhaps the 'noht' boot option should be reintroduced to initialise
> all cores, but only expose non-sibling cores to the OS (thus allowing
> C6)?
>
> Daniel
>
> tip: modprobe msr and use turbostat to monitor turbo-boost and C-state
> residency: http://bugzilla.kernel.org/attachment.cgi?id=24673

--
peng huang <huangpeng.linux@gmail.com>

==============================================================================
TOPIC: OOM-Killer kills too much with 2.6.32.2
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Jan 26 2010 5:20 am
From: Chris Wilson

On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> Please consider to revert such commit at once. Lots people reported
> the same issue.
> I really hope to stop bug report storm.

Your CC did not reference the problem that you were discussing, nor that
it is even easier to trigger an OOM without the shrinker. Memory
exhaustion due to the excess usage of surfaces from userspace is not a new
issuer. So what is the problem you have encountered and how does running
the OOM killer earlier fix the issue of triggering the OOM killer?

--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 5 ==
Date: Tues, Jan 26 2010 5:40 am
From: "Roman Jarosz"

On Tue, 26 Jan 2010 12:07:43 +0100, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:

> (Restore all cc and add Hugh and Chris)
>
>
>> > Hi all,
>> >
>> > Strangely, all reproduce machine are x86_64 with Intel i915. but I
>> don't
>> > have any solid evidence.
>> > Can anyone please apply following debug patch and reproduce this
>> issue?
>> >
>> > this patch write some debug message into /var/log/messages.
>> >
>>
>> Here it is
>>
>> Jan 26 09:34:32 kedge kernel: ->fault OOM shmem_fault 1 1
>> Jan 26 09:34:32 kedge kernel: X invoked oom-killer: gfp_mask=0x0,
>> order=0,
>> oom_adj=0
>> Jan 26 09:34:32 kedge kernel: Pid: 1927, comm: X Not tainted 2.6.33-rc5
>> #3
>
>
> Very thank you!!
>
> Current status and analysis are
> - OOM is invoked by VM_FAULT_OOM in page fault
> - GEM use lots shmem internally. i915 use GEM.
> - VM_FAULT_OOM is created by shmem.
> - shmem allocate some memory by using
> mapping_gfp_mask(inode->i_mapping).
> and if allocation failed, it can return -ENOMEM and -ENOMEM generate
> VM_FAULT_OOM.
> - But, GEM have following code.
>
>
> drm_gem.c drm_gem_object_alloc()
> --------------------
> obj->filp = shmem_file_setup("drm mm object", size,
> VM_NORESERVE);
> (snip)
> /* Basically we want to disable the OOM killer and handle ENOMEM
> * ourselves by sacrificing pages from cached buffers.
> * XXX shmem_file_[gs]et_gfp_mask()
> */
> mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> GFP_HIGHUSER |
> __GFP_COLD |
> __GFP_FS |
> __GFP_RECLAIMABLE |
> __GFP_NORETRY |
> __GFP_NOWARN |
> __GFP_NOMEMALLOC);
>
>
> This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
> GEM can't handle nor recover it. I suspect following commit is wrong.
>
> ----------------------------------------------------
> commit 07f73f6912667621276b002e33844ef283d98203
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Mon Sep 14 16:50:30 2009 +0100
>
> drm/i915: Improve behaviour under memory pressure
>
> Due to the necessity of having to take the struct_mutex, the i915
> shrinker can not free the inactive lists if we fail to allocate
> memory
> whilst processing a batch buffer, triggering an OOM and an ENOMEM
> that
> is reported back to userspace. In order to fare better under such
> circumstances we need to manually retry a failed allocation after
> evicting inactive buffers.
>
> To do so involves 3 steps:
> 1. Marking the backing shm pages as NORETRY.
> 2. Updating the get_pages() callers to evict something on failure
> and then
> retry.
> 3. Revamping the evict something logic to be smarter about the
> required
> buffer size and prefer to use volatile or clean inactive pages.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ----------------------------------------------------
>
>
> but unfortunatelly it can't revert easily.
> So, Can you please try following partial revert patch?
>
>
>
> From a27115f93d4f3ff6538860e69a7b444761cef91b Mon Sep 17 00:00:00 2001
> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Date: Tue, 26 Jan 2010 19:51:57 +0900
> Subject: [PATCH] Revert NORETRY
>
> ---
> drivers/gpu/drm/drm_gem.c | 13 -------------
> 1 files changed, 0 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index e9dbb48..8bf3770 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t
> size)
> if (IS_ERR(obj->filp))
> goto free;
> - /* Basically we want to disable the OOM killer and handle ENOMEM
> - * ourselves by sacrificing pages from cached buffers.
> - * XXX shmem_file_[gs]et_gfp_mask()
> - */
> - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> - GFP_HIGHUSER |
> - __GFP_COLD |
> - __GFP_FS |
> - __GFP_RECLAIMABLE |
> - __GFP_NORETRY |
> - __GFP_NOWARN |
> - __GFP_NOMEMALLOC);
> -
> kref_init(&obj->refcount);
> kref_init(&obj->handlecount);
> obj->size = size;

I've applied this patch and I'm testing it right now.
Btw. what this patch will do from user(my) point of view?

Regards
Roman

== 3 of 5 ==
Date: Tues, Jan 26 2010 6:00 am
From: Pekka Enberg

On Tue, Jan 26, 2010 at 7:19 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> (cc to lots related person)
>
>> On Mon, 25 Jan 2010 02:48:08 +0100, KOSAKI Motohiro
>> <kosaki.motohiro@jp.fujitsu.com> wrote:
>>
>> >> Hi,
>> >>
>> >> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
>> >> kills when I do hard disk intensive tasks (mainly in VirtualBox which is
>> >> running Windows XP) and IMHO it kills processes even if I have a lot of
>> >> free memory.
>> >>
>> >> Is this a known bug? I have self compiled kernel so I can try patches.
>> >
>> > Can you please post your .config?
>
> Hi all,
>
> Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> have any solid evidence.

The same oops seems to appear in an unrelated "screen going blank" bug
report (it's the second to last oops):

http://bugzilla.kernel.org/show_bug.cgi?id=15015
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 5 ==
Date: Tues, Jan 26 2010 6:10 am
From: Michael Reinelt

Michael Reinelt schrieb:
>
> Chris Wilson schrieb:
>> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>>> Please consider to revert such commit at once. Lots people reported
>>> the same issue.
>>> I really hope to stop bug report storm.
>> Your CC did not reference the problem that you were discussing, nor that
>> it is even easier to trigger an OOM without the shrinker. Memory
>> exhaustion due to the excess usage of surfaces from userspace is not a new
>> issuer. So what is the problem you have encountered and how does running
>> the OOM killer earlier fix the issue of triggering the OOM killer?
>>
>
> To end this discussion: I just had a OOM with the GEM / shmem partial revert patch from Motohiro :-(
>
> Unfortunately without Motohiro's oom-debug patch applied :-(
>
> as a non-git-user I have to manually patch memory.c, but I hope I can get things right. I will provide results ASAP.

Sorry sorry sorry... false alarm. One should also *install* a new kernel after compiling...

I'll give it another try, this time with OOM debugging applied.

sorry for the noise...

--
Michael Reinelt <michael@reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 5 of 5 ==
Date: Tues, Jan 26 2010 6:20 am
From: Michael Reinelt

Chris Wilson schrieb:
> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>> Please consider to revert such commit at once. Lots people reported
>> the same issue.
>> I really hope to stop bug report storm.
>
> Your CC did not reference the problem that you were discussing, nor that
> it is even easier to trigger an OOM without the shrinker. Memory
> exhaustion due to the excess usage of surfaces from userspace is not a new
> issuer. So what is the problem you have encountered and how does running
> the OOM killer earlier fix the issue of triggering the OOM killer?
>

To end this discussion: I just had a OOM with the GEM / shmem partial revert patch from Motohiro :-(

Unfortunately without Motohiro's oom-debug patch applied :-(

as a non-git-user I have to manually patch memory.c, but I hope I can get things right. I will provide results ASAP.

==============================================================================
TOPIC: radeon kms
http://groups.google.com/group/linux.kernel/t/da301c22e0b6fda3?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 5:30 am
From: John Kacur

On Fri, 15 Jan 2010, Jerome Glisse wrote:

> On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote:
> >
> >
> > On Fri, 15 Jan 2010, John Kacur wrote:
> >
> > > The oops is triggered because I am missing the firmware for
> > > radeon/R700_rlc.bin and
> > > radeon/R600_rlc.bin
> > >
> > > However, I think it should be able to deal with this more gracefully.
> > >
> > > ATOM BIOS: 9498.11.22.6.0.AS03
> > > [drm] Clocks initialized !
> > > [drm] Detected VRAM RAM=256M, BAR=256M
> > > [drm] RAM width 128bits DDR
> > > [TTM] Zone kernel: Available graphics memory: 3050912 kiB.
> > > [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
> > > [drm] radeon: 256M of VRAM memory ready
> > > [drm] radeon: 512M of GTT memory ready.
> > > alloc irq_desc for 33 on node -1
> > > alloc kstat_irqs on node -1
> > > radeon 0000:02:00.0: irq 33 for MSI/MSI-X
> > > [drm] radeon: using MSI.
> > > [drm] radeon: irq initialized.
> > > [drm] GART: num cpu pages 131072, num gpu pages 131072
> > > [drm] Loading RV730 Microcode
> > > platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin
> > > platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin
> > > platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin
> > > r600_cp: Failed to load firmware "radeon/R700_rlc.bin"
> > > [drm:rv770_startup] *ERROR* Failed to load firmware!
> > > radeon 0000:02:00.0: ffff8801a20b5400 unpin not necessary
> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
> > > IP: [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
> > > PGD 1a1a74067 PUD 1a19b8067 PMD 0
> > > Oops: 0000 [#1] SMP
> > > last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading
> > > CPU 4
> > > Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R
> > > RIP: 0010:[<ffffffffa0061034>] [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [t
> > > tm]
> > > RSP: 0018:ffff8801a1a8fb68 EFLAGS: 00010292
> > > RAX: ffff880100000000 RBX: 0000000000000000 RCX: 0000000000000000
> > > RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000048
> > > RBP: ffff8801a1a8fba8 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > > R13: ffff8801a8838000 R14: 0000000000000024 R15: 0000000000002000
> > > FS: 00007f0f9c6dc700(0000) GS:ffff88002e400000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > CR2: 0000000000000048 CR3: 00000001a195d000 CR4: 00000000000006e0
> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > Process modprobe (pid: 168, threadinfo ffff8801a1a8e000, task ffff8801a22c0000)
> > > Stack:
> > > ffff880100000000 ffff8801a27e2900 ffff8801a1a8fb88 0000000000000000
> > > <0> 0000000000000000 ffff8801a8838000 0000000000000024 0000000000002000
> > > <0> ffff8801a1a8fbd8 ffffffffa00ba05b ffff8801a1a8fbd8 ffff8801a27f4000
> > > Call Trace:
> > > [<ffffffffa00ba05b>] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon]
> > > [<ffffffffa00bb441>] rv770_suspend+0x43/0x69 [radeon]
> > > [<ffffffffa00bb6cf>] rv770_init+0x1a4/0x22d [radeon]
> > > [<ffffffffa0089593>] radeon_device_init+0x27f/0x300 [radeon]
> > > [<ffffffffa008a0fb>] radeon_driver_load_kms+0xff/0x184 [radeon]
> > > [<ffffffffa001e1a6>] drm_get_dev+0x3c4/0x4c5 [drm]
> > > [<ffffffff8122ea73>] ? pci_match_device+0x22/0xd0
> > > [<ffffffffa00c3bb8>] radeon_pci_probe+0x15/0x268 [radeon]
> > > [<ffffffff8122e941>] local_pci_probe+0x17/0x1b
> > > [<ffffffff8122f721>] pci_device_probe+0xcd/0xfd
> > > [<ffffffff812ce793>] ? driver_sysfs_add+0x4c/0x71
> > > [<ffffffff812ce95c>] driver_probe_device+0xde/0x1fe
> > > [<ffffffff812cead9>] __driver_attach+0x5d/0x81
> > > [<ffffffff812cea7c>] ? __driver_attach+0x0/0x81
> > > [<ffffffff812cdded>] bus_for_each_dev+0x59/0x8e
> > > [<ffffffff812ce6f2>] driver_attach+0x1e/0x20
> > > [<ffffffff812ce330>] bus_add_driver+0xd8/0x240
> > > [<ffffffff812cedcb>] driver_register+0x9d/0x10e
> > > [<ffffffff8122f969>] __pci_register_driver+0x68/0xd8
> > > [<ffffffff81439aa2>] ? printk+0x41/0x47
> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
> > > [<ffffffffa0018eb3>] drm_init+0x75/0xdb [drm]
> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
> > > [<ffffffffa00f70bf>] radeon_init+0xbf/0xc1 [radeon]
> > > [<ffffffff81002069>] do_one_initcall+0x5e/0x15e
> > > [<ffffffff81087788>] sys_init_module+0xd8/0x23a
> > > [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
> > > Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5
> > > 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 <4c> 8b 27 48 89 fb 41 88
> > > f5 41 88 d6 41 88 cf 44 89 45 c8 49 81
> > > RIP [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
> > > RSP <ffff8801a1a8fb68>
> > > CR2: 0000000000000048
> > > ---[ end trace 604e2e318733e108 ]---
> > > udevd-work[166]: '/sbin/modprobe -b pci:v00001002d00009498sv00001043sd00000300bc
> > > 03sc00i00' unexpected exit with status 0x0009
> > >
> > >
> >
> > I forgot to mention that this is kernel version 2.6.33-rc4.
> >
> > Thanks.
>
> Yes, we didn't paid enough attention to failure path :( Sorry for that
> Fix should be in next rc, patch is:
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=30d2d9a54d48e4fefede0389ded1b6fc2d44a522
>

I think your fix didn't make it to 2.6.33-rc5 because I'm still oopsing
when I don't grab the firmware from the internet. (instead of merely
reverting to vga mode).

Furthermore, why is the firmware not shipped with the kernel?
I never needed to fetch firmware for the 2.6.31 kernels and my graphic
card worked fine.

Am I right to conclude that the license is a problem?
http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon

This is a huge step backwards if we are exchanging a working driver with
what shipped with the linux kernel to one that only works with blobs that
don't ship with the kernel.

Thanks

John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 6:10 am
From: Alex Deucher

On Tue, Jan 26, 2010 at 8:21 AM, John Kacur <jkacur@redhat.com> wrote:
>
>
> On Fri, 15 Jan 2010, Jerome Glisse wrote:
>
>> On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote:
>> >
>> >
>> > On Fri, 15 Jan 2010, John Kacur wrote:
>> >
>> > > The oops is triggered because I am missing the firmware for
>> > > radeon/R700_rlc.bin and
>> > > radeon/R600_rlc.bin
>> > >
>> > > However, I think it should be able to deal with this more gracefully.
>> > >
>> > > ATOM BIOS: 9498.11.22.6.0.AS03
>> > > [drm] Clocks initialized !
>> > > [drm] Detected VRAM RAM=256M, BAR=256M
>> > > [drm] RAM width 128bits DDR
>> > > [TTM] Zone kernel: Available graphics memory: 3050912 kiB.
>> > > [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
>> > > [drm] radeon: 256M of VRAM memory ready
>> > > [drm] radeon: 512M of GTT memory ready.
>> > > alloc irq_desc for 33 on node -1
>> > > alloc kstat_irqs on node -1
>> > > radeon 0000:02:00.0: irq 33 for MSI/MSI-X
>> > > [drm] radeon: using MSI.
>> > > [drm] radeon: irq initialized.
>> > > [drm] GART: num cpu pages 131072, num gpu pages 131072
>> > > [drm] Loading RV730 Microcode
>> > > platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin
>> > > platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin
>> > > platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin
>> > > r600_cp: Failed to load firmware "radeon/R700_rlc.bin"
>> > > [drm:rv770_startup] *ERROR* Failed to load firmware!
>> > > radeon 0000:02:00.0: ffff8801a20b5400 unpin not necessary
>> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
>> > > IP: [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
>> > > PGD 1a1a74067 PUD 1a19b8067 PMD 0
>> > > Oops: 0000 [#1] SMP
>> > > last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading
>> > > CPU 4
>> > > Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R
>> > > RIP: 0010:[<ffffffffa0061034>] [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [t
>> > > tm]
>> > > RSP: 0018:ffff8801a1a8fb68 EFLAGS: 00010292
>> > > RAX: ffff880100000000 RBX: 0000000000000000 RCX: 0000000000000000
>> > > RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000048
>> > > RBP: ffff8801a1a8fba8 R08: 0000000000000000 R09: 0000000000000000
>> > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>> > > R13: ffff8801a8838000 R14: 0000000000000024 R15: 0000000000002000
>> > > FS: 00007f0f9c6dc700(0000) GS:ffff88002e400000(0000) knlGS:0000000000000000
>> > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> > > CR2: 0000000000000048 CR3: 00000001a195d000 CR4: 00000000000006e0
>> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> > > Process modprobe (pid: 168, threadinfo ffff8801a1a8e000, task ffff8801a22c0000)
>> > > Stack:
>> > > ffff880100000000 ffff8801a27e2900 ffff8801a1a8fb88 0000000000000000
>> > > <0> 0000000000000000 ffff8801a8838000 0000000000000024 0000000000002000
>> > > <0> ffff8801a1a8fbd8 ffffffffa00ba05b ffff8801a1a8fbd8 ffff8801a27f4000
>> > > Call Trace:
>> > > [<ffffffffa00ba05b>] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon]
>> > > [<ffffffffa00bb441>] rv770_suspend+0x43/0x69 [radeon]
>> > > [<ffffffffa00bb6cf>] rv770_init+0x1a4/0x22d [radeon]
>> > > [<ffffffffa0089593>] radeon_device_init+0x27f/0x300 [radeon]
>> > > [<ffffffffa008a0fb>] radeon_driver_load_kms+0xff/0x184 [radeon]
>> > > [<ffffffffa001e1a6>] drm_get_dev+0x3c4/0x4c5 [drm]
>> > > [<ffffffff8122ea73>] ? pci_match_device+0x22/0xd0
>> > > [<ffffffffa00c3bb8>] radeon_pci_probe+0x15/0x268 [radeon]
>> > > [<ffffffff8122e941>] local_pci_probe+0x17/0x1b
>> > > [<ffffffff8122f721>] pci_device_probe+0xcd/0xfd
>> > > [<ffffffff812ce793>] ? driver_sysfs_add+0x4c/0x71
>> > > [<ffffffff812ce95c>] driver_probe_device+0xde/0x1fe
>> > > [<ffffffff812cead9>] __driver_attach+0x5d/0x81
>> > > [<ffffffff812cea7c>] ? __driver_attach+0x0/0x81
>> > > [<ffffffff812cdded>] bus_for_each_dev+0x59/0x8e
>> > > [<ffffffff812ce6f2>] driver_attach+0x1e/0x20
>> > > [<ffffffff812ce330>] bus_add_driver+0xd8/0x240
>> > > [<ffffffff812cedcb>] driver_register+0x9d/0x10e
>> > > [<ffffffff8122f969>] __pci_register_driver+0x68/0xd8
>> > > [<ffffffff81439aa2>] ? printk+0x41/0x47
>> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
>> > > [<ffffffffa0018eb3>] drm_init+0x75/0xdb [drm]
>> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
>> > > [<ffffffffa00f70bf>] radeon_init+0xbf/0xc1 [radeon]
>> > > [<ffffffff81002069>] do_one_initcall+0x5e/0x15e
>> > > [<ffffffff81087788>] sys_init_module+0xd8/0x23a
>> > > [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
>> > > Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5
>> > > 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 <4c> 8b 27 48 89 fb 41 88
>> > > f5 41 88 d6 41 88 cf 44 89 45 c8 49 81
>> > > RIP [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
>> > > RSP <ffff8801a1a8fb68>
>> > > CR2: 0000000000000048
>> > > ---[ end trace 604e2e318733e108 ]---
>> > > udevd-work[166]: '/sbin/modprobe -b pci:v00001002d00009498sv00001043sd00000300bc
>> > > 03sc00i00' unexpected exit with status 0x0009
>> > >
>> > >
>> >
>> > I forgot to mention that this is kernel version 2.6.33-rc4.
>> >
>> > Thanks.
>>
>> Yes, we didn't paid enough attention to failure path :( Sorry for that
>> Fix should be in next rc, patch is:
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=30d2d9a54d48e4fefede0389ded1b6fc2d44a522
>>
>
> I think your fix didn't make it to 2.6.33-rc5 because I'm still oopsing
> when I don't grab the firmware from the internet. (instead of merely
> reverting to vga mode).
>
> Furthermore, why is the firmware not shipped with the kernel?
> I never needed to fetch firmware for the 2.6.31 kernels and my graphic
> card worked fine.
>
> Am I right to conclude that the license is a problem?
> http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon
>
> This is a huge step backwards if we are exchanging a working driver with
> what shipped with the linux kernel to one that only works with blobs that
> don't ship with the kernel.

In general, microcode is slowly being moved out of the kernel and into
the Linux firmware tree:
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree
Eventually all of the radeon microcode will end up out up in that tree.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Jan 26 2010 6:20 am
From: John Kacur

On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Tue, Jan 26, 2010 at 8:21 AM, John Kacur <jkacur@redhat.com> wrote:
>>
>>
>> On Fri, 15 Jan 2010, Jerome Glisse wrote:
>>
>>> On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote:
>>> >
>>> >
>>> > On Fri, 15 Jan 2010, John Kacur wrote:
>>> >
>>> > > The oops is triggered because I am missing the firmware for
>>> > > radeon/R700_rlc.bin and
>>> > > radeon/R600_rlc.bin
>>> > >
>>> > > However, I think it should be able to deal with this more gracefully.
>>> > >
>>> > > ATOM BIOS: 9498.11.22.6.0.AS03
>>> > > [drm] Clocks initialized !
>>> > > [drm] Detected VRAM RAM=256M, BAR=256M
>>> > > [drm] RAM width 128bits DDR
>>> > > [TTM] Zone kernel: Available graphics memory: 3050912 kiB.
>>> > > [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
>>> > > [drm] radeon: 256M of VRAM memory ready
>>> > > [drm] radeon: 512M of GTT memory ready.
>>> > > alloc irq_desc for 33 on node -1
>>> > > alloc kstat_irqs on node -1
>>> > > radeon 0000:02:00.0: irq 33 for MSI/MSI-X
>>> > > [drm] radeon: using MSI.
>>> > > [drm] radeon: irq initialized.
>>> > > [drm] GART: num cpu pages 131072, num gpu pages 131072
>>> > > [drm] Loading RV730 Microcode
>>> > > platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin
>>> > > platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin
>>> > > platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin
>>> > > r600_cp: Failed to load firmware "radeon/R700_rlc.bin"
>>> > > [drm:rv770_startup] *ERROR* Failed to load firmware!
>>> > > radeon 0000:02:00.0: ffff8801a20b5400 unpin not necessary
>>> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
>>> > > IP: [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
>>> > > PGD 1a1a74067 PUD 1a19b8067 PMD 0
>>> > > Oops: 0000 [#1] SMP
>>> > > last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading
>>> > > CPU 4
>>> > > Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R
>>> > > RIP: 0010:[<ffffffffa0061034>] [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [t
>>> > > tm]
>>> > > RSP: 0018:ffff8801a1a8fb68 EFLAGS: 00010292
>>> > > RAX: ffff880100000000 RBX: 0000000000000000 RCX: 0000000000000000
>>> > > RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000048
>>> > > RBP: ffff8801a1a8fba8 R08: 0000000000000000 R09: 0000000000000000
>>> > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>> > > R13: ffff8801a8838000 R14: 0000000000000024 R15: 0000000000002000
>>> > > FS: 00007f0f9c6dc700(0000) GS:ffff88002e400000(0000) knlGS:0000000000000000
>>> > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> > > CR2: 0000000000000048 CR3: 00000001a195d000 CR4: 00000000000006e0
>>> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> > > Process modprobe (pid: 168, threadinfo ffff8801a1a8e000, task ffff8801a22c0000)
>>> > > Stack:
>>> > > ffff880100000000 ffff8801a27e2900 ffff8801a1a8fb88 0000000000000000
>>> > > <0> 0000000000000000 ffff8801a8838000 0000000000000024 0000000000002000
>>> > > <0> ffff8801a1a8fbd8 ffffffffa00ba05b ffff8801a1a8fbd8 ffff8801a27f4000
>>> > > Call Trace:
>>> > > [<ffffffffa00ba05b>] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon]
>>> > > [<ffffffffa00bb441>] rv770_suspend+0x43/0x69 [radeon]
>>> > > [<ffffffffa00bb6cf>] rv770_init+0x1a4/0x22d [radeon]
>>> > > [<ffffffffa0089593>] radeon_device_init+0x27f/0x300 [radeon]
>>> > > [<ffffffffa008a0fb>] radeon_driver_load_kms+0xff/0x184 [radeon]
>>> > > [<ffffffffa001e1a6>] drm_get_dev+0x3c4/0x4c5 [drm]
>>> > > [<ffffffff8122ea73>] ? pci_match_device+0x22/0xd0
>>> > > [<ffffffffa00c3bb8>] radeon_pci_probe+0x15/0x268 [radeon]
>>> > > [<ffffffff8122e941>] local_pci_probe+0x17/0x1b
>>> > > [<ffffffff8122f721>] pci_device_probe+0xcd/0xfd
>>> > > [<ffffffff812ce793>] ? driver_sysfs_add+0x4c/0x71
>>> > > [<ffffffff812ce95c>] driver_probe_device+0xde/0x1fe
>>> > > [<ffffffff812cead9>] __driver_attach+0x5d/0x81
>>> > > [<ffffffff812cea7c>] ? __driver_attach+0x0/0x81
>>> > > [<ffffffff812cdded>] bus_for_each_dev+0x59/0x8e
>>> > > [<ffffffff812ce6f2>] driver_attach+0x1e/0x20
>>> > > [<ffffffff812ce330>] bus_add_driver+0xd8/0x240
>>> > > [<ffffffff812cedcb>] driver_register+0x9d/0x10e
>>> > > [<ffffffff8122f969>] __pci_register_driver+0x68/0xd8
>>> > > [<ffffffff81439aa2>] ? printk+0x41/0x47
>>> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
>>> > > [<ffffffffa0018eb3>] drm_init+0x75/0xdb [drm]
>>> > > [<ffffffffa00f7000>] ? radeon_init+0x0/0xc1 [radeon]
>>> > > [<ffffffffa00f70bf>] radeon_init+0xbf/0xc1 [radeon]
>>> > > [<ffffffff81002069>] do_one_initcall+0x5e/0x15e
>>> > > [<ffffffff81087788>] sys_init_module+0xd8/0x23a
>>> > > [<ffffffff81009bf2>] system_call_fastpath+0x16/0x1b
>>> > > Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5
>>> > > 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 <4c> 8b 27 48 89 fb 41 88
>>> > > f5 41 88 d6 41 88 cf 44 89 45 c8 49 81
>>> > > RIP [<ffffffffa0061034>] ttm_bo_reserve+0x16/0xf8 [ttm]
>>> > > RSP <ffff8801a1a8fb68>
>>> > > CR2: 0000000000000048
>>> > > ---[ end trace 604e2e318733e108 ]---
>>> > > udevd-work[166]: '/sbin/modprobe -b pci:v00001002d00009498sv00001043sd00000300bc
>>> > > 03sc00i00' unexpected exit with status 0x0009
>>> > >
>>> > >
>>> >
>>> > I forgot to mention that this is kernel version 2.6.33-rc4.
>>> >
>>> > Thanks.
>>>
>>> Yes, we didn't paid enough attention to failure path :( Sorry for that
>>> Fix should be in next rc, patch is:
>>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=30d2d9a54d48e4fefede0389ded1b6fc2d44a522
>>>
>>
>> I think your fix didn't make it to 2.6.33-rc5 because I'm still oopsing
>> when I don't grab the firmware from the internet. (instead of merely
>> reverting to vga mode).
>>
>> Furthermore, why is the firmware not shipped with the kernel?
>> I never needed to fetch firmware for the 2.6.31 kernels and my graphic
>> card worked fine.
>>
>> Am I right to conclude that the license is a problem?
>> http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon
>>
>> This is a huge step backwards if we are exchanging a working driver with
>> what shipped with the linux kernel to one that only works with blobs that
>> don't ship with the kernel.
>
> In general, microcode is slowly being moved out of the kernel and into
> the Linux firmware tree:
> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree
> Eventually all of the radeon microcode will end up out up in that tree.
>

Okay, but why are R600_rlc.bin R700_rlc.bin in particular missing
from the firmware?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: block: fix bio_add_page for non trivial merge_bvec_fn case
http://groups.google.com/group/linux.kernel/t/10f0ec95bfdc56f7?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 5:30 am
From: Jens Axboe

On Tue, Jan 26 2010, Dmitry Monakhov wrote:
> Hi, year ago I've sent a patch which fix false bio merge rejects, but
> seems patch was missed. Currently the issue is still present.
>

> From 92a97ef181e15caa94bd56a1ade5c337db599b79 Mon Sep 17 00:00:00 2001
> From: Dmitry Monakhov <dmonakhov@openvz.org>
> Date: Tue, 26 Jan 2010 16:01:34 +0300
> Subject: [PATCH] [PATCH] block: fix bio_add_page for non trivial merge_bvec_fn case
>
> We have to properly decrease bi_size in order to merge_bvec_fn return
> right result. Otherwise this result in false merge rejects for two
> absolutely valid bio_vecs. This may cause significant performance penalty
> for example Itanium: page_size == 16k, fs_block_size == 1k and block device
> is raid with small chunk_size.
>
> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
> ---
> fs/bio.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/bio.c b/fs/bio.c
> index 76e6713..9f8e517 100644
> --- a/fs/bio.c
> +++ b/fs/bio.c
> @@ -548,7 +548,8 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
> struct bvec_merge_data bvm = {
> .bi_bdev = bio->bi_bdev,
> .bi_sector = bio->bi_sector,
> - .bi_size = bio->bi_size,
> + .bi_size = bio->bi_size -
> + (prev->bv_len - len),
> .bi_rw = bio->bi_rw,
> };

Hmm confused. why isn't this just bio->bi_size - len?

--
Jens Axboe

== 2 of 2 ==
Date: Tues, Jan 26 2010 6:20 am
From: Dmitry Monakhov

On Tue, Jan 26, 2010 at 4:29 PM, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jan 26 2010, Dmitry Monakhov wrote:
>> Hi, year ago I've sent a patch which fix false bio merge rejects, but
>> seems patch was missed. Currently the issue is still present.
>>
>
>> From 92a97ef181e15caa94bd56a1ade5c337db599b79 Mon Sep 17 00:00:00 2001
>> From: Dmitry Monakhov <dmonakhov@openvz.org>
>> Date: Tue, 26 Jan 2010 16:01:34 +0300
>> Subject: [PATCH] [PATCH] block: fix bio_add_page for non trivial merge_bvec_fn case
>>
>> We have to properly decrease bi_size in order to merge_bvec_fn return
>> right result. Otherwise this result in false merge rejects for two
>> absolutely valid bio_vecs. This may cause significant performance penalty
>> for example Itanium: page_size == 16k, fs_block_size == 1k and block device
>> is raid with small chunk_size.
>>
>> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
>> ---
>> fs/bio.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/bio.c b/fs/bio.c
>> index 76e6713..9f8e517 100644
>> --- a/fs/bio.c
>> +++ b/fs/bio.c
>> @@ -548,7 +548,8 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
>> struct bvec_merge_data bvm = {
>> .bi_bdev = bio->bi_bdev,
>> .bi_sector = bio->bi_sector,
>> - .bi_size = bio->bi_size,
>> + .bi_size = bio->bi_size -
>> + (prev->bv_len - len),
>> .bi_rw = bio->bi_rw,
>> };
>
> Hmm confused. why isn't this just bio->bi_size - len?
because we have following scenario:
0) old_bv_len = prev->bv_len ;
1) prev->bv_len += len;
2)->merge_bvec_fn()
usually it looks like follows
if (bio->bv_len + bvm->bi_size > max_chunk_size)
goto fail
So formally we detach last bvec increase it size and try to
attach it to bio.

but old_bv_len is already accounted in bi_size, so we have to decrease
bi_size to this value, and old_bv_len = (prev->bv_len - len) at
that moment.
I've used math manipuation in order to avoid temporary variable
because stack size is matter on block layer.
>
> --
> Jens Axboe
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: request for assistance: accessing ttys from kernel space
http://groups.google.com/group/linux.kernel/t/cd06029f40862317?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 5:40 am
From: Alan Cox

> Is there another way to set up a line discipline from the kernel itself
> without the need from userland intervention, even before any / is
> mounted?

There is no fundamental reason you can't do that once the tty object
itself exists. Currently there is no path for doing it in the kernel.

> Maybe the early serial console support layer could be extended a bit so
> speakup can use it first during the boot? For now it's quite tied to
> just printing the printk logs. drivers/accessibility/braille_console.c
> does manage do make something else, but it happens that the
> serial_core.c's uart_console_write puts additional \rs before \ns, which
> can be a problem.
>
> Also, for proper speech flow, speakup would need to be able to read
> characters from the device.

Some debugger folk want that too.

I've been trying to get to the point where each tty consists of a
tty_struct which is the instance of an opened tty device, and a tty_port
which is a common struct instance for each physical port. That then has
some operations attached to it.

However at the moment most of the operation paths are not pushed into
tty_port, not every device yet has a tty_port and many of the paths that
need pushing into tty_port reference material that is in struct tty but
probably also needs moving.

So there is an awful lot of work to be done.

I guess the quick 'get it working' hack for the moment would be to add a
'raw' flag to the console output routines and use those (where raw=1
would mean 'don't tamper with the formatting')

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: mm/readahead.c: update the LRU positions of in-core pages, too
http://groups.google.com/group/linux.kernel/t/c3e8affbeb80ebe0?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 5:40 am
From: Wu Fengguang

On Mon, Jan 25, 2010 at 03:36:35PM -0700, Chris Frost wrote:
> I changed Wu's patch to add a PageLRU() guard that I believe is required
> and optimized zone lock acquisition to only unlock and lock at zone changes.
> This optimization seems to provide a 10-20% system time improvement for
> some of my GIMP benchmarks and no improvement for other benchmarks.

> + del_page_from_lru_list(zone, page, lru);
> + add_page_to_lru_list(zone, page, lru);
> + }
> + put_page(page);

Hmm. put_page() inside lru_lock can deadlock. So you need to further
optimize the code to do pagevec_lookup() and pagevec_release() plus
cond_resched().

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: usb: otg: add notifier support
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 5:40 am
From: David Brownell

On Tuesday 26 January 2010, Mark Brown wrote:
> On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote:
>
> > I'd vote to convert all the USB-to-charger interfaces so
> > they use notifiers. After fixing the events ... see
> > comments below. :)
>
> Yes please - it's not just chargers either, this can also be used by
> PMICs which do power path management that includes USB.

Color me confused ... what do you mean by "power path"?

Do you mean something like "the board as a whole can take N mA of
current from USB", rather than specifically addressing a charger?

It's not uncommon to do things like use VBUS current to power the
USB circuitry, too. That can leave less for other purposes. All
of that being rather board-specific.

> > Those seem like the wrong events. The right events for a charger
> > would be more along the lines of:
>
> > - For peripheral: "you may use N milliAmperes now".
> > - General: "Don't Charge" (a.k.a. "use 0 mA").
>
> > I don't see how "N" would be passed with those events ...
>
> These are good for the peripheral side. You do get to pass a void *
> along with the notifier value, that could be used to pass data like the
> current limit.

I don't think I saw that being done ... either in code, comments,
or documentation. Passing N is fundamental.

> > A host *might* want to be able to say things like "supply
> > up to N milliAmperes now", e.g. to let a regulator choose
> > the most efficient mode.
>
> Yes, they definitely want this - not just for efficiency but also to
> allow current limiting to protect the system from excessive current
> drain.

There are load bursting issues too. All part of the USB spec;
a load that's OK for 1 millisecond might not be OK for 1 second.
ISTR the "supply N mA" refers to an average. And there are some
limits to the capacitance that can practically be stuck on VBUS
output lines (which includes the cable). Solvable problems, but
not always pretty if software has to think it through.

Thing is, supplying current is a bit more involved. If the
board can't supply 300 mA, the USB configuration selection
mechanism has to know that, so it never selects peripheral
configurations which require that much current.

Or maybe these two ports can serve 500 mA, but not those two;
or their total can't exceed N (function of componentry and power
budgeting).

Ergo my desire to start with a straightforward problem whose
solution has real value (how much VBUS current may be consumed?),
and leave some of those other messes for later!

- Dave

== 2 of 3 ==
Date: Tues, Jan 26 2010 6:20 am
From: Felipe Balbi

On Tue, Jan 26, 2010 at 02:35:21PM +0100, ext David Brownell wrote:
>On Tuesday 26 January 2010, Mark Brown wrote:
>> On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote:
>>
>> > I'd vote to convert all the USB-to-charger interfaces so
>> > they use notifiers. After fixing the events ... see
>> > comments below. :)
>>
>> Yes please - it's not just chargers either, this can also be used by
>> PMICs which do power path management that includes USB.
>
>Color me confused ... what do you mean by "power path"?
>
>Do you mean something like "the board as a whole can take N mA of
>current from USB", rather than specifically addressing a charger?
>
>It's not uncommon to do things like use VBUS current to power the
>USB circuitry, too. That can leave less for other purposes. All
>of that being rather board-specific.
>
>
>> > Those seem like the wrong events. The right events for a charger
>> > would be more along the lines of:
>>
>> > - For peripheral: "you may use N milliAmperes now".
>> > - General: "Don't Charge" (a.k.a. "use 0 mA").
>>
>> > I don't see how "N" would be passed with those events ...
>>
>> These are good for the peripheral side. You do get to pass a void *
>> along with the notifier value, that could be used to pass data like the
>> current limit.
>
>I don't think I saw that being done ... either in code, comments,
>or documentation. Passing N is fundamental.

yeah, my bad. I should have said that, but it's more related to the
implementation of the notifier_block.

>> > A host *might* want to be able to say things like "supply
>> > up to N milliAmperes now", e.g. to let a regulator choose
>> > the most efficient mode.
>>
>> Yes, they definitely want this - not just for efficiency but also to
>> allow current limiting to protect the system from excessive current
>> drain.
>
>There are load bursting issues too. All part of the USB spec;
>a load that's OK for 1 millisecond might not be OK for 1 second.

if you get a SetConfiguration(config), then you can use that load for as
long as needed, the limitation is when not enumerated, afaict.

>ISTR the "supply N mA" refers to an average. And there are some
>limits to the capacitance that can practically be stuck on VBUS
>output lines (which includes the cable). Solvable problems, but
>not always pretty if software has to think it through.
>
>Thing is, supplying current is a bit more involved. If the
>board can't supply 300 mA, the USB configuration selection
>mechanism has to know that, so it never selects peripheral
>configurations which require that much current.

but that's done already by the usb core, no ? It rules out configuration
based on the hub->power_budget (can't remember if the field is that
exact name).

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Jan 26 2010 6:20 am
From: Felipe Balbi

Hi,

On Tue, Jan 26, 2010 at 12:16:20PM +0100, ext David Brownell wrote:
>On Friday 11 December 2009, Felipe Balbi wrote:
>> The notifier will be used to communicate usb events
>> to other drivers like the charger chip.
>
>Good idea ... but not OTG-specific. It doesn't seem to me

thanks

>that charging hookups belong in that header at all.

I noticed that when started actually using it :-)

>In fact, usb_gadget_vbus_draw() might better be implemented
>as such a notifier call, removing that configuration mess
>from the usb gadget drivers ("how can I know what charger
>to use??"). That would be the most common situation: a
>peripheral-only device.
>
>And in fact, OTG can be treated as a trivial superset of
>peripheral-only USB. (In terms of charger support, only!!)
>
>I'd vote to convert all the USB-to-charger interfaces so
>they use notifiers. After fixing the events ... see
>comments below. :)

makes sense

>> @@ -9,6 +9,8 @@
>> #ifndef __LINUX_USB_OTG_H
>> #define __LINUX_USB_OTG_H
>>
>> +#include <linux/notifier.h>
>> +
>> /* OTG defines lots of enumeration states before device reset */
>> enum usb_otg_state {
>> OTG_STATE_UNDEFINED = 0,
>> @@ -33,6 +35,14 @@ enum usb_otg_state {
>> OTG_STATE_A_VBUS_ERR,
>> };
>>
>> +enum usb_xceiv_events {
>
>Let's keep charger events separate from anything else,
>like "enter host mode" or "enter peripheral mode" (or
>even "disconnect"). The audiences for any other types
>of event would be entirely different.

the idea was to notify USB events to interested drivers, not only "usb
charger events".

>Right now there's a mess in terms of charger hookup,
>so getting that straight is IMO a priority over any
>other type of event. Using events will decouple a
>bunch of drivers, and simplify driver configuration.

well, if you consider that this transceiver isn't really otg specific,
then this is already wrong.

>> + USB_EVENT_NONE, /* no events or cable disconnected */
>> + USB_EVENT_VBUS, /* vbus valid event */
>> + USB_EVENT_ID, /* id was grounded */
>> + USB_EVENT_CHARGER, /* usb dedicated charger */
>> + USB_EVENT_ENUMERATED, /* gadget driver enumerated */
>
>Those seem like the wrong events. The right events for a charger
>would be more along the lines of:
>
> - For peripheral: "you may use N milliAmperes now".
> - General: "Don't Charge" (a.k.a. "use 0 mA").

I have to disagree, which information would you used to kick the usb
dedicated charger detection other than VBUS irq from transceiver ?

So we need at least that, and also need to notify when the charger
detection is finished, so we can enable data pullups on the link.
Remember we might be connected to a charging downstream port.

>I don't see how "N" would be passed with those events ...

there's a void * we can use to pass bMaxPower field of the selected
configuration.

>Haven't looked at the details of the charger spec, but
>those two events are the *basics* from the USB 2.0 spec,
>so "official" charger hardware wouldn't be less capable.

I believe the dedicated charger is also "basic".

>Thing like different levels of VBUS validity, ID grounding,
>and so forth ... wouldn't be very relevant. An OTG driver
>will do various things, internally, when ID grounds; but
>anything else is a function of what role eventually gets
>negotiated. And for the charger, they all add up to "Don't
>Charge" (since ID grounded means A-role, sourcing power).

ID grounding event is necessary if you have an external charge pump.
At least the boards I've been working use an external chip as the USB
Charger and Charge pump, iow, the transceiver doesn't source VBUS on ID
ground, but the charger chip is put into "boost" mode for that role.

>> #define USB_OTG_PULLUP_ID (1 << 0)
>> #define USB_OTG_PULLDOWN_DP (1 << 1)
>> #define USB_OTG_PULLDOWN_DM (1 << 2)
>> @@ -70,6 +80,9 @@ struct otg_transceiver {
>> struct otg_io_access_ops *io_ops;
>> void __iomem *io_priv;
>>
>> + /* for notification of usb_xceiv_events */
>> + struct blocking_notifier_head notifier;
>
>Why "blocking"? That seems kind of unnatural; for example,
>the main users -- like usb_gadget_vbus_draw() -- would be
>called in IRQ context (blocking not allowed).

what about irqs running in thread, wouldn't we "BUG sleeping in irq
context" ?

==============================================================================
TOPIC: linux-next: add utrace tree
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:00 am
From: Pavel Machek

On Fri 2010-01-22 08:43:18, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 22 Jan 2010 10:51:39 +0530, Ananth N Mavinakayanahalli said:
>
> > FWIW, Oleg's implementation of ptrace over utrace is 100% compatible
> > with legacy ptrace; gdb testsuite indicates that
> > (http://lkml.org/lkml/2009/12/21/98).
>
> No, that only proves it's compatible enough for gdb to not care. The problem
> is all those *other* packages that abuse ptrace in totally crackhead ways.
>
> (No, I can't name them - but ptrace is the sort of interface that almost
> encourages its use for things somewhere between crackhead and mad-scientist,
> so they're almost certainly out there.. WAY out there.. :)

strace, subterfugue, ltrace, ...? Plus various homegrown sandboxing tools...
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: betra yal predi ctabl e satur able aleat oric varia blity
http://groups.google.com/group/linux.kernel/t/687424b83ca486f9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:00 am
From:

libel ing roubl es grind er attor n randi es gastr ectom y expos
itory negat ive hydro xy vigou rless serot inous terro rised
pamph letiz es itali cises tradi tiona l crowi ng total iser
natio nwide churn ers skimp faste ns nomad ize grand niece betra
yal regis tries negat ive prism atic osteo logic al sardo nical
ly pande rer prope rness headw inds regul ator hombr e zeist
aleat oric esseq uibo misro uting unfor geabl e thios ulfur ic
total iser uncla morou s aleat oric pleas ance aimle ssnes s
tamar ind colle t bashe r packe d decad ence enerv ative iodic
tame

==============================================================================
TOPIC: System panic under load with clockevents_program_event
http://groups.google.com/group/linux.kernel/t/8dc02ff411331726?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:10 am
From: okias

Lastest git without HIGHMEM look good. If no problems occur, then I
try use kernel with HIGHMEM and see what change...

2010/1/25, okias <d.okias@gmail.com>:
> Okey, I try without highmem soon.
>
> 2010/1/25, Thomas Gleixner <tglx@linutronix.de>:
>> Switched to email. Please reply to all instead of using the bugzilla
>> interface.
>>
>>> --- Comment #4 from okias <d.okias@gmail.com> 2010-01-22 10:17:25 ---
>>> and it's regression. Now I work on 2.6.32.3 and no problem.
>>
>> That's a really weird one. The system is 50 min up and running and out
>> of the blue it crashes in clockevents_program_event(). This function
>> has been called a couple of thousand times before that point.
>>
>> The only way to crash there is when *dev is pointing into nirwana. dev
>> comes from
>>
>> int tick_program_event(ktime_t expires, int force)
>> {
>> struct clock_event_device *dev =
>> __get_cpu_var(tick_cpu_device).evtdev;
>>
>> according to the callchain. At this point nothing fiddles with
>> tick_cpu_device.evtdev, so I suspect some really nasty memory
>> corruption going on.
>>
>> okias, can you please disable highmem support and verify whether the
>> problem persists ?
>>
>> Thanks,
>>
>> tglx
>>
>
>
> --
> Jabber/XMPP: okias@isgeek.info
> SIP VoIP: sip:17474537254@proxy01.sipphone.com
>

--
Jabber/XMPP: okias@isgeek.info
SIP VoIP: sip:17474537254@proxy01.sipphone.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
http://groups.google.com/group/linux.kernel/t/e208566420ffb479?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:20 am
From: Pavel Machek

On Mon 2010-01-25 22:54:37, Rafael J. Wysocki wrote:
> On Monday 25 January 2010, Alan Cox wrote:
> > > > But in that case we should be able to disable the VT switch disable
> > > > path; we just have to check each driver as it's loaded.
> > >
> > > OK, what the right sequence of checks would be in that case and where to place
> > > them?
> >
> > Why are we even driving a vt switch direct from the suspend/resume
> > logic ? The problem starts there. If it was being handled off the device
> > suspend/resume method then there wouldn't be a mess to start with ?
> >
> > Start at the beginning
> >
> > - Why do we switch to arbitarily chosen 'last vt'
> > - Why isn't vt related suspend/resume handled by the device
>
> Well, that was added long ago as a workaround for some problems people
> reported (presumably). I've never looked at that before, so I can't really
> tell why someone did it this particular way.

As X drives hardware, it is/was neccessary to get control out of X and
console switch was convenient.

Note that it needs to happen with userland still active -- before
freezer.

And yes, it should be per-driver these days.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: clocksource: Prevent potential kgdb dead lock
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:20 am
From: tip-bot for Thomas Gleixner

Commit-ID: 7b7422a566aa0dc1e582ce263d4c7ff4a772700a
Gitweb: http://git.kernel.org/tip/7b7422a566aa0dc1e582ce263d4c7ff4a772700a
Author: Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Tue, 26 Jan 2010 12:51:10 +0100
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 26 Jan 2010 14:53:16 +0100

clocksource: Prevent potential kgdb dead lock

commit 0f8e8ef7 (clocksource: Simplify clocksource watchdog resume
logic) introduced a potential kgdb dead lock. When the kernel is
stopped by kgdb inside code which holds watchdog_lock then kgdb dead
locks in clocksource_resume_watchdog().

clocksource_resume_watchdog() is called from kbdg via
clocksource_touch_watchdog() to avoid that the clock source watchdog
marks TSC unstable after the kernel has been stopped.

Solve this by replacing spin_lock with a spin_trylock and just return
in case the lock is held. Not resetting the watchdog might result in
TSC becoming marked unstable, but that's an acceptable penalty for
using kgdb.

The timekeeping is anyway easily screwed up by kgdb when the system
uses either jiffies or a clock source which wraps in short intervals
(e.g. pm_timer wraps about every 4.6s), so we really do not have to
worry about that occasional TSC marked unstable side effect.

The second caller of clocksource_resume_watchdog() is
clocksource_resume(). The trylock is safe here as well because the
system is UP at this point, interrupts are disabled and nothing else
can hold watchdog_lock().

Reported-by: Jason Wessel <jason.wessel@windriver.com>
LKML-Reference: <1264480000-6997-4-git-send-email-jason.wessel@windriver.com>
Cc: kgdb-bugreport@lists.sourceforge.net
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/time/clocksource.c | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index e85c234..1370083 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -343,7 +343,19 @@ static void clocksource_resume_watchdog(void)
{
unsigned long flags;

- spin_lock_irqsave(&watchdog_lock, flags);
+ /*
+ * We use trylock here to avoid a potential dead lock when
+ * kgdb calls this code after the kernel has been stopped with
+ * watchdog_lock held. When watchdog_lock is held we just
+ * return and accept, that the watchdog might trigger and mark
+ * the monitored clock source (usually TSC) unstable.
+ *
+ * This does not affect the other caller clocksource_resume()
+ * because at this point the kernel is UP, interrupts are
+ * disabled and nothing can hold watchdog_lock.
+ */
+ if (!spin_trylock_irqsave(&watchdog_lock, flags))
+ return;
clocksource_reset_watchdog();
spin_unlock_irqrestore(&watchdog_lock, flags);
}
@@ -458,8 +470,8 @@ void clocksource_resume(void)
* clocksource_touch_watchdog - Update watchdog
*
* Update the watchdog after exception contexts such as kgdb so as not
- * to incorrectly trip the watchdog.
- *
+ * to incorrectly trip the watchdog. This might fail when the kernel
+ * was stopped in code which holds watchdog_lock.
*/
void clocksource_touch_watchdog(void)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: PROBLEM: freeze on ppp connection (using an usb "key" modem)
http://groups.google.com/group/linux.kernel/t/2da2ca2c0a18eb99?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:20 am
From: Fabio Bas - Officine Informatiche

On 26/01/2010 13:54, Oliver Neukum wrote:
> Am Dienstag, 26. Januar 2010 13:53:08 schrieb Rafael J. Wysocki:
>> On Tuesday 26 January 2010, Fabio Bas - Officine Informatiche wrote:
>> ...
>>> The last working kernel i'm aware of is kernel 2.6.30, the first showing
>>> the problem 2.6.32.2
>>
>> Can you test 2.6.31.x please?
I'll download, compile and test it asap

>
> Is there a bugzilla for this?

I've just created it and attached all of my logs
http://bugzilla.kernel.org/show_bug.cgi?id=15146

> Sysrq-t?

Here's my new crash log; sysrq-t output refers to the time after the
connection was estabilished but before the freeze. I've tried to
alt+sysrq+t dìseveral times when the box was freezed, but i had no reply
from the kernel.

Jan 26 14:30:36 ambassador kernel: PPP generic driver version 2.4.2
Jan 26 14:30:36 ambassador pppd[5976]: pppd 2.4.4 started by root, uid 0
Jan 26 14:30:37 ambassador chat[5978]: send (ATZ^M)
Jan 26 14:30:37 ambassador chat[5978]: expect (OK^M^J)
Jan 26 14:30:37 ambassador chat[5978]: ATZ^M^M
Jan 26 14:30:37 ambassador chat[5978]: OK^M
Jan 26 14:30:37 ambassador chat[5978]: -- got it
Jan 26 14:30:37 ambassador chat[5978]: send (AT+CGDCONT=1,"IP","internet"^M)
Jan 26 14:30:37 ambassador chat[5978]: expect (OK^M^J)
Jan 26 14:30:37 ambassador chat[5978]: AT+CGDCONT=1,"IP","internet"^M^M
Jan 26 14:30:37 ambassador chat[5978]: OK^M
Jan 26 14:30:37 ambassador chat[5978]: -- got it
Jan 26 14:30:37 ambassador chat[5978]: send (ATDT*99***1#^M)
Jan 26 14:30:37 ambassador chat[5978]: expect (CONNECT)
Jan 26 14:30:37 ambassador chat[5978]: ATDT*99***1#^M^M
Jan 26 14:30:37 ambassador chat[5978]: CONNECT
Jan 26 14:30:37 ambassador chat[5978]: -- got it
Jan 26 14:30:37 ambassador chat[5978]: send (^M)
Jan 26 14:30:37 ambassador chat[5978]: expect (^M^J)
Jan 26 14:30:37 ambassador chat[5978]: 7200000^M
Jan 26 14:30:37 ambassador chat[5978]: -- got it
Jan 26 14:30:37 ambassador pppd[5976]: Serial connection established.
Jan 26 14:30:37 ambassador pppd[5976]: Using interface ppp0
Jan 26 14:30:37 ambassador pppd[5976]: Connect: ppp0 <--> /dev/ttyHS3
Jan 26 14:30:38 ambassador kernel: PPP BSD Compression module registered
Jan 26 14:30:38 ambassador kernel: PPP Deflate Compression module registered
Jan 26 14:30:39 ambassador pppd[5976]: local IP address 93.68.131.123
Jan 26 14:30:39 ambassador pppd[5976]: remote IP address 10.64.64.64
Jan 26 14:30:39 ambassador pppd[5976]: primary DNS address 83.224.65.143
Jan 26 14:30:39 ambassador pppd[5976]: secondary DNS address 83.224.66.138
Jan 26 14:30:40 ambassador kernel: scsi 29:0:0:0: Direct-Access
ZCOption HSUPA Modem PQ: 0 ANSI: 2
Jan 26 14:30:40 ambassador kernel: sd 29:0:0:0: Attached scsi generic
sg2 type 0
Jan 26 14:30:40 ambassador kernel: sd 29:0:0:0: [sdb] 3964928 512-byte
logical blocks: (2.03 GB/1.89 GiB)
Jan 26 14:30:40 ambassador kernel: sd 29:0:0:0: [sdb] Write Protect is off
Jan 26 14:30:40 ambassador kernel: sdb: sdb1
Jan 26 14:30:40 ambassador kernel: sd 29:0:0:0: [sdb] Attached SCSI
removable disk
Jan 26 14:31:04 ambassador /usr/sbin/gpm[2285]: *** info [client.c(137)]:
Jan 26 14:31:04 ambassador /usr/sbin/gpm[2285]: Connecting at fd 6
Jan 26 14:31:32 ambassador /usr/sbin/gpm[2285]: *** info [client.c(275)]:
Jan 26 14:31:32 ambassador /usr/sbin/gpm[2285]: Request on 6 (console 1)
Jan 26 14:31:32 ambassador /usr/sbin/gpm[2285]: *** info [client.c(284)]:
Jan 26 14:31:32 ambassador /usr/sbin/gpm[2285]: Closing
Jan 26 14:32:28 ambassador kernel: 00000
Jan 26 14:32:28 ambassador kernel: flush-8:0 S 0000000000000000
0 1902 2 0x00000000
Jan 26 14:32:28 ambassador kernel: kondemand/0 S ffff88000180dd88
0 1969 2 0x00000000
Jan 26 14:32:28 ambassador kernel: kondemand/1 S ffff88000190dd88
0 1970 2 0x00000000
Jan 26 14:32:28 ambassador kernel: syslogd S ffff88000180dd88
0 2016 1 0x00000000
Jan 26 14:32:28 ambassador kernel: klogd S ffff88007f908000
0 2020 1 0x00000000
Jan 26 14:32:28 ambassador kernel: acpid S ffff88000190dd88
0 2149 1 0x00000000
Jan 26 14:32:28 ambassador kernel: dbus-daemon S ffff88000180dd88
0 2161 1 0x00000000
Jan 26 14:32:28 ambassador kernel: hald S ffff88000180dd88
0 2166 1 0x00000000
Jan 26 14:32:28 ambassador kernel: hald-runner S ffff88000190dd88
0 2167 2166 0x00000000
Jan 26 14:32:28 ambassador kernel: hald-addon-in S ffff88000180dd88
0 2195 2167 0x00000000
Jan 26 14:32:28 ambassador kernel: hald-addon-cp S 0000000000000000
0 2199 2167 0x00000000
Jan 26 14:32:28 ambassador kernel: hald-addon-ac S ffff88007bf81d08
0 2200 2167 0x00000000
Jan 26 14:32:28 ambassador kernel: hald-addon-st S ffff88007bd53b88
0 2207 2167 0x00000000
Jan 26 14:32:28 ambassador kernel: cupsd S ffff88000180dd88
0 2237 1 0x00000000
Jan 26 14:32:28 ambassador kernel: wicd S ffff88000190dd88
0 2239 1 0x00000000
Jan 26 14:32:28 ambassador kernel: crond S ffff88000180dd88
0 2252 1 0x00000000
Jan 26 14:32:28 ambassador kernel: atd S ffff88000180dd88
0 2254 1 0x00000000
Jan 26 14:32:28 ambassador kernel: wicd-monitor S ffff88000190dd88
0 2269 2239 0x00000000
Jan 26 14:32:28 ambassador kernel: gpm S 0000000000000040
0 2285 1 0x00000000
Jan 26 14:32:28 ambassador kernel: agetty S ffff88000180dd88
0 2304 1 0x00000000
Jan 26 14:32:28 ambassador kernel: dhcpcd ? ffff88000180dd88
0 5158 2239 0x00000000
Jan 26 14:32:28 ambassador kernel: bash S ffff88000190dd88
0 5833 1 0x00000000
Jan 26 14:32:28 ambassador kernel: bash S ffff88000180dd88
0 5834 1 0x00000000
Jan 26 14:32:28 ambassador kernel: agetty S ffff88006e45bf50
0 5835 1 0x00000000
Jan 26 14:32:28 ambassador kernel: agetty S ffff88007ed84900
0 5836 1 0x00000000
Jan 26 14:32:28 ambassador kernel: agetty S ffff88006e45bee0
0 5837 1 0x00000000
Jan 26 14:32:28 ambassador kernel: scsi_eh_29 S ffff88000180dd88
0 5930 2 0x00000000
Jan 26 14:32:28 ambassador kernel: usb-storage S ffff88000c109a80
0 5931 2 0x00000000
Jan 26 14:32:28 ambassador kernel: pppd S ffff88000180dd88
0 5976 1 0x00000000
Jan 26 14:32:28 ambassador kernel: hald-addon-st S ffff880079551b88
0 6014 2167 0x00000000
Jan 26 14:32:44 ambassador /usr/sbin/gpm[2285]: *** info [client.c(137)]:
Jan 26 14:32:44 ambassador /usr/sbin/gpm[2285]: Connecting at fd 6
Jan 26 14:34:29 ambassador /usr/sbin/gpm[2285]: *** info [client.c(275)]:
Jan 26 14:34:29 ambassador /usr/sbin/gpm[2285]: Request on 6 (console 1)
Jan 26 14:34:29 ambassador /usr/sbin/gpm[2285]: *** info [client.c(284)]:
Jan 26 14:34:29 ambassador /usr/sbin/gpm[2285]: Closing
Jan 26 14:34:31 ambassador /usr/sbin/gpm[2285]: *** info [client.c(137)]:
Jan 26 14:34:31 ambassador /usr/sbin/gpm[2285]: Connecting at fd 6
Jan 26 14:35:13 ambassador /usr/sbin/gpm[2285]: *** info [client.c(275)]:
Jan 26 14:35:13 ambassador /usr/sbin/gpm[2285]: Request on 6 (console 1)
Jan 26 14:35:13 ambassador /usr/sbin/gpm[2285]: *** info [client.c(284)]:
Jan 26 14:35:13 ambassador /usr/sbin/gpm[2285]: Closing
Jan 26 14:36:02 ambassador kernel: CPU 1:
Jan 26 14:36:02 ambassador kernel: Pid: 0, comm: swapper Not tainted
2.6.32.5 #2 Satellite A210
Jan 26 14:36:02 ambassador kernel: RIP: 0010:[<ffffffff81014488>]
[<ffffffff81014488>] default_idle+0x38/0x80
Jan 26 14:36:02 ambassador kernel: RSP: 0018:ffff88007f8c5eb8 EFLAGS:
00000246
Jan 26 14:36:02 ambassador kernel: RAX: 0000000000000000 RBX:
ffff88007f8c5ec8 RCX: 0000000000000000
Jan 26 14:36:02 ambassador kernel: RDX: 0000000000000001 RSI:
0000000000000086 RDI: 0000000000000000
Jan 26 14:36:02 ambassador kernel: RBP: ffffffff8100c10e R08:
0000000000000000 R09: 0000000000001920
Jan 26 14:36:02 ambassador kernel: R10: 0000000000000002 R11:
00000001007667fc R12: 0000000000000004
Jan 26 14:36:02 ambassador kernel: R13: 0000000000000292 R14:
ffff88007f8c0000 R15: 00000001007667fc
Jan 26 14:36:02 ambassador kernel: FS: 00007fe5bdb987e0(0000)
GS:ffff880001900000(0000) knlGS:0000000000000000
Jan 26 14:36:02 ambassador kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Jan 26 14:36:02 ambassador kernel: CR2: 00007fe5b0d74f70 CR3:
000000006ee8e000 CR4: 00000000000006e0
Jan 26 14:36:02 ambassador kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jan 26 14:36:02 ambassador kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Jan 26 14:36:02 ambassador kernel: CPU 1:
Jan 26 14:36:02 ambassador kernel: Pid: 0, comm: swapper Not tainted
2.6.32.5 #2 Satellite A210
Jan 26 14:36:02 ambassador kernel: RIP: 0010:[<ffffffff813e1be0>]
[<ffffffff813e1be0>] _spin_lock_bh+0x20/0x40
Jan 26 14:36:02 ambassador kernel: RSP: 0018:ffff880001903e00 EFLAGS:
00000286
Jan 26 14:36:02 ambassador kernel: RAX: 0000000000009f9f RBX:
ffff880001903e10 RCX: ffff88007b715c90
Jan 26 14:36:02 ambassador kernel: RDX: ffff88007b715c90 RSI:
ffff8800791aee00 RDI: ffff8800793f367c
Jan 26 14:36:02 ambassador kernel: RBP: ffffffff8100c113 R08:
0000000000000000 R09: ffff88007eb2d150
Jan 26 14:36:02 ambassador kernel: R10: 0000000000001000 R11:
0000000000000001 R12: ffff880001903d80
Jan 26 14:36:02 ambassador kernel: R13: ffff8800793f367c R14:
ffff8800793f3600 R15: ffff8800791aee00
Jan 26 14:36:02 ambassador kernel: FS: 00007ff0bbbec740(0000)
GS:ffff880001900000(0000) knlGS:0000000000000000
Jan 26 14:36:02 ambassador kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Jan 26 14:36:02 ambassador kernel: CR2: 00007fe5b0d74f70 CR3:
000000000c224000 CR4: 00000000000006e0
Jan 26 14:36:02 ambassador kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jan 26 14:36:02 ambassador kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Jan 26 14:36:52 ambassador kernel: CPU 1:
Jan 26 14:36:52 ambassador kernel: Pid: 0, comm: swapper Not tainted
2.6.32.5 #2 Satellite A210
Jan 26 14:36:52 ambassador kernel: RIP: 0010:[<ffffffff8103fe92>]
[<ffffffff8103fe92>] finish_task_switch+0x52/0xc0
Jan 26 14:36:52 ambassador kernel: RSP: 0018:ffff88007f8c5e08 EFLAGS:
00000286
Jan 26 14:36:52 ambassador kernel: RAX: 000000000000f7c0 RBX:
ffff88007f8c5e38 RCX: 0000000000000000
Jan 26 14:36:52 ambassador kernel: RDX: 0000000000000001 RSI:
0000000000000001 RDI: ffff88007f8a27c0
Jan 26 14:36:52 ambassador kernel: RBP: ffffffff8100c10e R08:
ffff88007f8c4000 R09: 0000000000000000
Jan 26 14:36:52 ambassador kernel: R10: 0000000000000000 R11:
0000000000000000 R12: ffffffff810747c4
Jan 26 14:36:52 ambassador kernel: R13: ffff88007f8c5d78 R14:
ffffffff810242ed R15: ffff88007f8c5d68
Jan 26 14:36:52 ambassador kernel: FS: 00007fa2e4e02780(0000)
GS:ffff880001900000(0000) knlGS:0000000000000000
Jan 26 14:36:52 ambassador kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Jan 26 14:36:52 ambassador kernel: CR2: 000000000230f6a4 CR3:
000000006129a000 CR4: 00000000000006e0
Jan 26 14:36:52 ambassador kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jan 26 14:36:52 ambassador kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Jan 26 14:37:11 ambassador kernel: CPU 1:
Jan 26 14:37:11 ambassador kernel: Pid: 0, comm: swapper Not tainted
2.6.32.5 #2 Satellite A210
Jan 26 14:37:11 ambassador kernel: RIP: 0010:[<ffffffff81014488>]
[<ffffffff81014488>] default_idle+0x38/0x80
Jan 26 14:37:11 ambassador kernel: RSP: 0018:ffff88007f8c5eb8 EFLAGS:
00000246
Jan 26 14:37:11 ambassador kernel: RAX: 0000000000000000 RBX:
ffff88007f8c5ec8 RCX: 0000000000000000
Jan 26 14:37:11 ambassador kernel: RDX: 0000000000000001 RSI:
0000000000000086 RDI: 0000000000000000
Jan 26 14:37:11 ambassador kernel: RBP: ffffffff8100c10e R08:
0000000000000000 R09: ffff88000190e148
Jan 26 14:37:11 ambassador kernel: R10: 00000764a2424598 R11:
0000000100777386 R12: 0000000000000004
Jan 26 14:37:11 ambassador kernel: R13: 0000000000000292 R14:
ffff88007f8c0000 R15: 0000000100777386
Jan 26 14:37:11 ambassador kernel: FS: 00007f9c97a9e740(0000)
GS:ffff880001900000(0000) knlGS:0000000000000000
Jan 26 14:37:11 ambassador kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Jan 26 14:37:11 ambassador kernel: CR2: 00000000055bf9b8 CR3:
000000007b624000 CR4: 00000000000006e0
Jan 26 14:37:11 ambassador kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jan 26 14:37:11 ambassador kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Jan 26 14:37:24 ambassador kernel: CPU 1:
Jan 26 14:37:24 ambassador kernel: Pid: 0, comm: swapper Not tainted
2.6.32.5 #2 Satellite A210
Jan 26 14:37:24 ambassador kernel: RIP: 0010:[<ffffffff81014488>]
[<ffffffff81014488>] default_idle+0x38/0x80
Jan 26 14:37:24 ambassador kernel: RSP: 0018:ffff88007f8c5eb8 EFLAGS:
00000246
Jan 26 14:37:24 ambassador kernel: RAX: 0000000000000000 RBX:
ffff88007f8c5ec8 RCX: 0000000000000000
Jan 26 14:37:24 ambassador kernel: RDX: 0000000000000001 RSI:
0000000000000086 RDI: 0000000000000000
Jan 26 14:37:24 ambassador kernel: RBP: ffffffff8100c10e R08:
0000000000000000 R09: ffff88000190e148
Jan 26 14:37:24 ambassador kernel: R10: 00000767b5048c00 R11:
000000010077a7bc R12: 0000000000000004
Jan 26 14:37:24 ambassador kernel: R13: 0000000000000292 R14:
ffff88007f8c0000 R15: 000000010077a7bb
Jan 26 14:37:24 ambassador kernel: FS: 00007ff0bbbec740(0000)
GS:ffff880001900000(0000) knlGS:0000000000000000
Jan 26 14:37:24 ambassador kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Jan 26 14:37:24 ambassador kernel: CR2: 0000000000989060 CR3:
000000000c224000 CR4: 00000000000006e0
Jan 26 14:37:24 ambassador kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jan 26 14:37:24 ambassador kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Jan 26 14:37:25 ambassador kernel: CPU 1:
Jan 26 14:37:25 ambassador kernel: Pid: 0, comm: swapper Not tainted
2.6.32.5 #2 Satellite A210
Jan 26 14:37:25 ambassador kernel: RIP: 0010:[<ffffffff8101453f>]
[<ffffffff8101453f>] c1e_idle+0x6f/0x110
Jan 26 14:37:25 ambassador kernel: RSP: 0018:ffff88007f8c5ef0 EFLAGS:
00000296
Jan 26 14:37:25 ambassador kernel: RAX: 0000000000000001 RBX:
ffff88007f8c5ef8 RCX: 0000000000000000
Jan 26 14:37:25 ambassador kernel: RDX: 000000000000f22b RSI:
0000000000000096 RDI: ffffffff816a2d80
Jan 26 14:37:25 ambassador kernel: RBP: ffffffff8100c10e R08:
ffff88000190cce0 R09: 0000000000000000
Jan 26 14:37:25 ambassador kernel: R10: 0000000000000002 R11:
000000010077ad09 R12: 0000000000000005
Jan 26 14:37:25 ambassador kernel: R13: 0000000000000000 R14:
ffffffff8106cdd7 R15: ffff88007f8c5e88
Jan 26 14:37:25 ambassador kernel: FS: 00007ff0bbbec740(0000)
GS:ffff880001900000(0000) knlGS:0000000000000000
Jan 26 14:37:25 ambassador kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Jan 26 14:37:25 ambassador kernel: CR2: 00007f04d488b650 CR3:
000000000c224000 CR4: 00000000000006e0
Jan 26 14:37:25 ambassador kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Jan 26 14:37:25 ambassador kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400

> Which driver cdc-acm or a serial driver?

Serial (my modem device is /dev/ttyHS3):

root@ambassador:~# cat /proc/tty/drivers
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
hso /dev/ttyHS 249 0-255 serial
serial /dev/ttyS 4 64-67 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
pty_slave /dev/ttyp 3 0-31 pty:slave
pty_master /dev/pty 2 0-31 pty:master
unknown /dev/tty 4 1-63 console

>
> Regards
> Oliver
>
>

Thank you :)

fabio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: fs: re-order super_block to remove 16 bytes of padding on 64bit builds
http://groups.google.com/group/linux.kernel/t/6ca13e5299dd1f6b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 6:20 am
From: Richard Kennedy

re-order structure super_block to remove 16 bytes of alignment padding
on 64bit builds.

This shrinks the size of super_block from 712 to 696 bytes so requiring
one fewer 64 byte cache lines.

Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>

-----
patch against 2.6.33-rc5
compiled & tested on x86_64 AMDX2 desktop machine.

I've been running with this patch applied for several weeks with no
problems.

regards
Richard

diff --git a/include/linux/fs.h b/include/linux/fs.h
index b1bcb27..a2f87ea 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1314,9 +1314,9 @@ extern spinlock_t sb_lock;
struct super_block {
struct list_head s_list; /* Keep this first */
dev_t s_dev; /* search index; _not_ kdev_t */
- unsigned long s_blocksize;
- unsigned char s_blocksize_bits;
unsigned char s_dirt;
+ unsigned char s_blocksize_bits;
+ unsigned long s_blocksize;
loff_t s_maxbytes; /* Max file size */
struct file_system_type *s_type;
const struct super_operations *s_op;
@@ -1357,16 +1357,16 @@ struct super_block {
void *s_fs_info; /* Filesystem private info */
fmode_t s_mode;

+ /* Granularity of c/m/atime in ns.
+ Cannot be worse than a second */
+ u32 s_time_gran;
+
/*
* The next field is for VFS *only*. No filesystems have any business
* even looking at it. You had been warned.
*/
struct mutex s_vfs_rename_mutex; /* Kludge */

- /* Granularity of c/m/atime in ns.
- Cannot be worse than a second */
- u32 s_time_gran;
-
/*
* Filesystem subtype. If non-empty the filesystem type field
* in /proc/mounts will be "type.subtype"

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, January 26, 2010

linux.kernel - 26 new messages in 15 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts