Re: 4.14 kernel and acpi INT3400:00: Unsupported event [0x86]

[Arkadiusz Miskiewicz]

On Wednesday 15 of November 2017, Zhang Rui wrote:
> Hi, Brian,
> 
> thanks for your quick fix, as it is in merge window right now, I will
> queue it for for next -rc2.

Don't see it merged (4.15.0-rc8). Any problems with it?

> 
> thanks,
> rui
> 
> On Tue, 2017-11-14 at 10:50 -0700, Brian Bian wrote:
> > I have submitted a patch to suppress such messages. The INT3400
> > driver
> > currently handles 0x83 thermal-relationship-table-change event
> > only, and all other ACPI notification codes are unknown/irrelevant
> > to the INT3400 driver.
> > 
> > Thanks,
> > -Brian
> > 
> > On Mon, 13 Nov 2017, Arkadiusz Miskiewicz wrote:
> > > On Monday 13 of November 2017, Zhang Rui wrote:
> > > > On Sun, 2017-11-12 at 23:25 +0100, Arkadiusz Miskiewicz wrote:
> > > > > Hello.
> > > > > 
> > > > > On Dell XPS 9530 and 4.14 kernel dmesg is flooded with:
> > > > > 
> > > > > [  292.580807] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  299.284648] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  305.648079] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  315.444799] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  317.432412] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  319.420239] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  321.408476] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  323.400304] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  325.388358] acpi INT3400:00: Unsupported event [0x86]
> > > > > 
> > > > > What 0x86 might mean?
> > > > 
> > > > please attach the acpidump output.
> > > 
> > > Attached.
> > > 
> > > > thanks,
> > > > rui
> > > 
> > > -- 
> > > Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: 4.14 kernel and acpi INT3400:00: Unsupported event [0x86]

[Arkadiusz Miskiewicz]

On Wednesday 15 of November 2017, Zhang Rui wrote:
> Hi, Brian,
> 
> thanks for your quick fix, as it is in merge window right now, I will
> queue it for for next -rc2.

Don't see it merged (4.15.0-rc8). Any problems with it?

> 
> thanks,
> rui
> 
> On Tue, 2017-11-14 at 10:50 -0700, Brian Bian wrote:
> > I have submitted a patch to suppress such messages. The INT3400
> > driver
> > currently handles 0x83 thermal-relationship-table-change event
> > only, and all other ACPI notification codes are unknown/irrelevant
> > to the INT3400 driver.
> > 
> > Thanks,
> > -Brian
> > 
> > On Mon, 13 Nov 2017, Arkadiusz Miskiewicz wrote:
> > > On Monday 13 of November 2017, Zhang Rui wrote:
> > > > On Sun, 2017-11-12 at 23:25 +0100, Arkadiusz Miskiewicz wrote:
> > > > > Hello.
> > > > > 
> > > > > On Dell XPS 9530 and 4.14 kernel dmesg is flooded with:
> > > > > 
> > > > > [  292.580807] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  299.284648] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  305.648079] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  315.444799] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  317.432412] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  319.420239] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  321.408476] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  323.400304] acpi INT3400:00: Unsupported event [0x86]
> > > > > [  325.388358] acpi INT3400:00: Unsupported event [0x86]
> > > > > 
> > > > > What 0x86 might mean?
> > > > 
> > > > please attach the acpidump output.
> > > 
> > > Attached.
> > > 
> > > > thanks,
> > > > rui
> > > 
> > > -- 
> > > Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

4.14 kernel and acpi INT3400:00: Unsupported event [0x86]

[Arkadiusz Miskiewicz]

Hello.

On Dell XPS 9530 and 4.14 kernel dmesg is flooded with:

[  292.580807] acpi INT3400:00: Unsupported event [0x86]
[  299.284648] acpi INT3400:00: Unsupported event [0x86]
[  305.648079] acpi INT3400:00: Unsupported event [0x86]
[  315.444799] acpi INT3400:00: Unsupported event [0x86]
[  317.432412] acpi INT3400:00: Unsupported event [0x86]
[  319.420239] acpi INT3400:00: Unsupported event [0x86]
[  321.408476] acpi INT3400:00: Unsupported event [0x86]
[  323.400304] acpi INT3400:00: Unsupported event [0x86]
[  325.388358] acpi INT3400:00: Unsupported event [0x86]

What 0x86 might mean?

It was added by commit:

commit 38e44da591303d08b0d965a033e11ade284999d0
Author: Brian Bian 
Date:   Wed Aug 9 11:45:40 2017 -0700

thermal: int3400_thermal: process "thermal table changed" event

Some BIOS implement ACPI notification code 0x83 to indicate active
relationship table(ART) and/or thermal relationship table(TRT) changes
to INT3400 device. This event needs to be propagated to user space so
that it can be handled by the user space thermal daemon.

Signed-off-by: Brian Bian 
Signed-off-by: Zhang Rui 

# dmesg
[0.00] microcode: microcode updated early to revision 0x22, date = 
2017-01-27
[0.00] Linux version 4.14.0 (arekm@ixion-pld) (gcc version 7.2.0 
20170814 (release) (PLD-Linux)) #188 SMP PREEMPT Sun Nov 12 22:42:24 CET 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.14-stable 
root=UUID=af81d682-6bd2-4d3e-86e4-ece699b48fb4 ro panic=120 init=/bin/systemd 
systemd.unit=graphical.target pause_on_oops=30 kaslr intel_pstate=disable 
systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xb8446fff] usable
[0.00] BIOS-e820: [mem 0xb8447000-0xb844dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xb844e000-0xb888bfff] usable
[0.00] BIOS-e820: [mem 0xb888c000-0xb8ea7fff] reserved
[0.00] BIOS-e820: [mem 0xb8ea8000-0xca793fff] usable
[0.00] BIOS-e820: [mem 0xca794000-0xcab46fff] reserved
[0.00] BIOS-e820: [mem 0xcab47000-0xcab69fff] ACPI data
[0.00] BIOS-e820: [mem 0xcab6a000-0xcb53efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcb53f000-0xcbffefff] reserved
[0.00] BIOS-e820: [mem 0xcbfff000-0xcbff] usable
[0.00] BIOS-e820: [mem 0xcd00-0xcf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00042fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Dell Inc. XPS 15 9530/XPS 15 9530, BIOS A09 07/30/2015
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x42fe00 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 7C write-back
[0.00]   1 base 04 mask 7FE000 write-back
[0.00]   2 base 042000 mask 7FF000 write-back
[0.00]   3 base 00E000 mask 7FE000 uncachable
[0.00]   4 base 00D000 mask 7FF000 uncachable
[0.00]   5 base 00CE00 mask 

4.14 kernel and acpi INT3400:00: Unsupported event [0x86]

[Arkadiusz Miskiewicz]

Hello.

On Dell XPS 9530 and 4.14 kernel dmesg is flooded with:

[  292.580807] acpi INT3400:00: Unsupported event [0x86]
[  299.284648] acpi INT3400:00: Unsupported event [0x86]
[  305.648079] acpi INT3400:00: Unsupported event [0x86]
[  315.444799] acpi INT3400:00: Unsupported event [0x86]
[  317.432412] acpi INT3400:00: Unsupported event [0x86]
[  319.420239] acpi INT3400:00: Unsupported event [0x86]
[  321.408476] acpi INT3400:00: Unsupported event [0x86]
[  323.400304] acpi INT3400:00: Unsupported event [0x86]
[  325.388358] acpi INT3400:00: Unsupported event [0x86]

What 0x86 might mean?

It was added by commit:

commit 38e44da591303d08b0d965a033e11ade284999d0
Author: Brian Bian 
Date:   Wed Aug 9 11:45:40 2017 -0700

thermal: int3400_thermal: process "thermal table changed" event

Some BIOS implement ACPI notification code 0x83 to indicate active
relationship table(ART) and/or thermal relationship table(TRT) changes
to INT3400 device. This event needs to be propagated to user space so
that it can be handled by the user space thermal daemon.

Signed-off-by: Brian Bian 
Signed-off-by: Zhang Rui 

# dmesg
[0.00] microcode: microcode updated early to revision 0x22, date = 
2017-01-27
[0.00] Linux version 4.14.0 (arekm@ixion-pld) (gcc version 7.2.0 
20170814 (release) (PLD-Linux)) #188 SMP PREEMPT Sun Nov 12 22:42:24 CET 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.14-stable 
root=UUID=af81d682-6bd2-4d3e-86e4-ece699b48fb4 ro panic=120 init=/bin/systemd 
systemd.unit=graphical.target pause_on_oops=30 kaslr intel_pstate=disable 
systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xb8446fff] usable
[0.00] BIOS-e820: [mem 0xb8447000-0xb844dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xb844e000-0xb888bfff] usable
[0.00] BIOS-e820: [mem 0xb888c000-0xb8ea7fff] reserved
[0.00] BIOS-e820: [mem 0xb8ea8000-0xca793fff] usable
[0.00] BIOS-e820: [mem 0xca794000-0xcab46fff] reserved
[0.00] BIOS-e820: [mem 0xcab47000-0xcab69fff] ACPI data
[0.00] BIOS-e820: [mem 0xcab6a000-0xcb53efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcb53f000-0xcbffefff] reserved
[0.00] BIOS-e820: [mem 0xcbfff000-0xcbff] usable
[0.00] BIOS-e820: [mem 0xcd00-0xcf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00042fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Dell Inc. XPS 15 9530/XPS 15 9530, BIOS A09 07/30/2015
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x42fe00 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 7C write-back
[0.00]   1 base 04 mask 7FE000 write-back
[0.00]   2 base 042000 mask 7FF000 write-back
[0.00]   3 base 00E000 mask 7FE000 uncachable
[0.00]   4 base 00D000 mask 7FF000 uncachable
[0.00]   5 base 00CE00 mask 7FFE00 uncachable
[0.00]   6 base 00CD00 mask 7FFF00 

stack gap fix for 4.1

[Arkadiusz Miskiewicz]

Hi.

I'm looking for stack gap fix backport for 4.1 (it's not in 4.1 stable queue 
git unfortunately).

I wonder if any distro still maintains 4.1 and could already make backport?

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

stack gap fix for 4.1

[Arkadiusz Miskiewicz]

Hi.

I'm looking for stack gap fix backport for 4.1 (it's not in 4.1 stable queue 
git unfortunately).

I wonder if any distro still maintains 4.1 and could already make backport?

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: aacraid: kernel: AAC: Host adapter dead -1 (bisected)

[Arkadiusz Miskiewicz]

On Tuesday 17 of January 2017, Dave Carroll wrote:
> > Hi.
> > 
> > There is a bug with handling of adaptec raid cards (in my case it is
> > Adaptec 3405) where kernel logs hundreds of "AAC: Host adapter dead -1"
> > messages.
> > 
> > Bug was reported previously on lkml but there was no progres in solving
> > it.
> > 
> > There is also bugzilla entry:
> > https://bugzilla.kernel.org/show_bug.cgi?id=151661
> > 
> > I've bisected that to commit bellow and indeed, reverting it from kernel
> > 4.9.3 makes messages go away.
> > 
> > Could anyone at microsemi look at this regression?
> > 
> > Thanks
> 
> Hi Arkadiusz,
> 
> Thanks for your effort in determining the cause of the issue. It makes
> sense now that the patch should have been included in controller specific
> code, rather than common code.
> 
> I will prepare a patch for this, and if you are willing to test it, that
> would be great!

Great!

I have dedicated machine for testing this, so yes - I'll test.

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: aacraid: kernel: AAC: Host adapter dead -1 (bisected)

[Arkadiusz Miskiewicz]

On Tuesday 17 of January 2017, Dave Carroll wrote:
> > Hi.
> > 
> > There is a bug with handling of adaptec raid cards (in my case it is
> > Adaptec 3405) where kernel logs hundreds of "AAC: Host adapter dead -1"
> > messages.
> > 
> > Bug was reported previously on lkml but there was no progres in solving
> > it.
> > 
> > There is also bugzilla entry:
> > https://bugzilla.kernel.org/show_bug.cgi?id=151661
> > 
> > I've bisected that to commit bellow and indeed, reverting it from kernel
> > 4.9.3 makes messages go away.
> > 
> > Could anyone at microsemi look at this regression?
> > 
> > Thanks
> 
> Hi Arkadiusz,
> 
> Thanks for your effort in determining the cause of the issue. It makes
> sense now that the patch should have been included in controller specific
> code, rather than common code.
> 
> I will prepare a patch for this, and if you are willing to test it, that
> would be great!

Great!

I have dedicated machine for testing this, so yes - I'll test.

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

aacraid: kernel: AAC: Host adapter dead -1 (bisected)

[Arkadiusz Miskiewicz]

Hi.

There is a bug with handling of adaptec raid cards (in my case it is Adaptec 
3405) where kernel logs hundreds of "AAC: Host adapter dead -1" messages.

Bug was reported previously on lkml but there was no progres in solving it.

There is also bugzilla entry:
https://bugzilla.kernel.org/show_bug.cgi?id=151661

I've bisected that to commit bellow and indeed, reverting it from kernel 4.9.3 
makes messages go away.

Could anyone at microsemi look at this regression?

Thanks

commit 78cbccd3bd683c295a44af8050797dc4a41376ff
Author: Raghava Aditya Renukunta 
Date:   Mon Apr 25 23:32:37 2016 -0700

aacraid: Fix for KDUMP driver hang

When KDUMP is triggered the driver first talks to the firmware in INTX
mode, but the adapter firmware is still in MSIX mode. Therefore the first
driver command hangs since the driver is waiting for an INTX response and
firmware gives a MSIX response. If when the OS is installed on a RAID
drive created by the adapter KDUMP will hang since the driver does not
receive a response in sync mode.

Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
sending the first sync command.

Cc: sta...@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta 

Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 

my hardware:
02:0e.0 RAID bus controller [0104]: Adaptec AAC-RAID [9005:0285]
Subsystem: Adaptec 3405 [9005:02bb]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping+ SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 

aacraid: kernel: AAC: Host adapter dead -1 (bisected)

[Arkadiusz Miskiewicz]

Hi.

There is a bug with handling of adaptec raid cards (in my case it is Adaptec 
3405) where kernel logs hundreds of "AAC: Host adapter dead -1" messages.

Bug was reported previously on lkml but there was no progres in solving it.

There is also bugzilla entry:
https://bugzilla.kernel.org/show_bug.cgi?id=151661

I've bisected that to commit bellow and indeed, reverting it from kernel 4.9.3 
makes messages go away.

Could anyone at microsemi look at this regression?

Thanks

commit 78cbccd3bd683c295a44af8050797dc4a41376ff
Author: Raghava Aditya Renukunta 
Date:   Mon Apr 25 23:32:37 2016 -0700

aacraid: Fix for KDUMP driver hang

When KDUMP is triggered the driver first talks to the firmware in INTX
mode, but the adapter firmware is still in MSIX mode. Therefore the first
driver command hangs since the driver is waiting for an INTX response and
firmware gives a MSIX response. If when the OS is installed on a RAID
drive created by the adapter KDUMP will hang since the driver does not
receive a response in sync mode.

Fixed by: Change the firmware to INTX mode if it is in MSIX mode before
sending the first sync command.

Cc: sta...@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta 

Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 

my hardware:
02:0e.0 RAID bus controller [0104]: Adaptec AAC-RAID [9005:0285]
Subsystem: Adaptec 3405 [9005:02bb]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping+ SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 

Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions

[Arkadiusz Miskiewicz]

On Tuesday 06 of September 2016, Vlastimil Babka wrote:
> After several people reported OOM's for order-2 allocations in 4.7 due to
> Michal Hocko's OOM rework, he reverted the part that considered compaction
> feedback [1] in the decisions to retry reclaim/compaction. This was to
> provide a fix quickly for 4.8 rc and 4.7 stable series, while mmotm had an
> almost complete solution that instead improved compaction reliability.
> 
> This series completes the mmotm solution and reintroduces the compaction
> feedback into OOM decisions. The first two patches restore the state of
> mmotm before the temporary solution was merged, the last patch should be
> the missing piece for reliability. The third patch restricts the hardened
> compaction to non-costly orders, since costly orders don't result in OOMs
> in the first place.
> 
> Some preliminary testing suggested that this approach should work, but I
> would like to ask all who experienced the regression to please retest
> this. You will need to apply this series on top of tag
> mmotm-2016-08-31-16-06 from the mmotm git tree [2]. Thanks in advance!

My "rm -rf copyX; cp -al org copyX" test x10 in parallel worked without any 
OOM.


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions

[Arkadiusz Miskiewicz]

On Tuesday 06 of September 2016, Vlastimil Babka wrote:
> After several people reported OOM's for order-2 allocations in 4.7 due to
> Michal Hocko's OOM rework, he reverted the part that considered compaction
> feedback [1] in the decisions to retry reclaim/compaction. This was to
> provide a fix quickly for 4.8 rc and 4.7 stable series, while mmotm had an
> almost complete solution that instead improved compaction reliability.
> 
> This series completes the mmotm solution and reintroduces the compaction
> feedback into OOM decisions. The first two patches restore the state of
> mmotm before the temporary solution was merged, the last patch should be
> the missing piece for reliability. The third patch restricts the hardened
> compaction to non-costly orders, since costly orders don't result in OOMs
> in the first place.
> 
> Some preliminary testing suggested that this approach should work, but I
> would like to ask all who experienced the regression to please retest
> this. You will need to apply this series on top of tag
> mmotm-2016-08-31-16-06 from the mmotm git tree [2]. Thanks in advance!

My "rm -rf copyX; cp -al org copyX" test x10 in parallel worked without any 
OOM.


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: OOM detection regressions since 4.7

[Arkadiusz Miskiewicz]

On Thursday 25 of August 2016, Michal Hocko wrote:
> On Tue 23-08-16 09:43:39, Michal Hocko wrote:
> > On Mon 22-08-16 15:05:17, Andrew Morton wrote:
> > > On Mon, 22 Aug 2016 15:42:28 +0200 Michal Hocko  
wrote:
> > > > Of course, if Linus/Andrew doesn't like to take those compaction
> > > > improvements this late then I will ask to merge the partial revert to
> > > > Linus tree as well and then there is not much to discuss.
> > > 
> > > This sounds like the prudent option.  Can we get 4.8 working
> > > well-enough, backport that into 4.7.x and worry about the fancier stuff
> > > for 4.9?
> > 
> > OK, fair enough.
> > 
> > I would really appreciate if the original reporters could retest with
> > this patch on top of the current Linus tree.
> 
> Any luck with the testing of this patch?

Here my "rm -rf && cp -al" 10x in parallel test finished without OOM, so

Tested-by: Arkadiusz Miśkiewicz 

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: OOM detection regressions since 4.7

[Arkadiusz Miskiewicz]

On Thursday 25 of August 2016, Michal Hocko wrote:
> On Tue 23-08-16 09:43:39, Michal Hocko wrote:
> > On Mon 22-08-16 15:05:17, Andrew Morton wrote:
> > > On Mon, 22 Aug 2016 15:42:28 +0200 Michal Hocko  
wrote:
> > > > Of course, if Linus/Andrew doesn't like to take those compaction
> > > > improvements this late then I will ask to merge the partial revert to
> > > > Linus tree as well and then there is not much to discuss.
> > > 
> > > This sounds like the prudent option.  Can we get 4.8 working
> > > well-enough, backport that into 4.7.x and worry about the fancier stuff
> > > for 4.9?
> > 
> > OK, fair enough.
> > 
> > I would really appreciate if the original reporters could retest with
> > this patch on top of the current Linus tree.
> 
> Any luck with the testing of this patch?

Here my "rm -rf && cp -al" 10x in parallel test finished without OOM, so

Tested-by: Arkadiusz Miśkiewicz 

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: Linux 4.1.28

[Arkadiusz Miskiewicz]

On Wednesday 20 of July 2016, Arkadiusz Miskiewicz wrote:
> On Friday 15 of July 2016, Thomas Voegtle wrote:
> > On Fri, 15 Jul 2016, Sasha Levin wrote:
> > > On 07/15/2016 07:38 AM, Thomas Voegtle wrote:
> > >> On Wed, 13 Jul 2016, Sasha Levin wrote:
> > >>> I'm announcing the release of the 4.1.28 kernel.
> > >> 
> > >> I have a serious memleak with 4.1.28 (like 20mb/s)
> > >> I stripped down my kernel config and started a bisect, which came to:
> > >> 
> > >> # first bad commit: [c5ad33184354260be6d05de57e46a5498692f6d6]
> > >> mm/swap.c: flush lru pvecs on compound page arrival
> > >> =>
> > >> commit c5ad33184354260be6d05de57e46a5498692f6d6
> > >> Author: Lukasz Odzioba <lukasz.odzi...@intel.com>
> > >> Date:   Fri Jun 24 14:50:01 2016 -0700
> > >> 
> > >> mm/swap.c: flush lru pvecs on compound page arrival
> > >> 
> > >> Reverting this on top 4.1.28 helps. Config attached.
> > > 
> > > Yup, this was reported and a fix is already queued for 4.1.29.
> > 
> > And that one?
> > Happens while trying to start a firewall script with iptables-restore.
> > 
> > 
> > [  180.071999] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
> > [iptables-restor:2338]
> 
> Same here but I don't have actuall trace
> 
> Applying iptables firewall rules...[
> 42.297704] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [iptables-
> restor:900]
> [   70.287999] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s!
> [iptables-restor:900]
> [  102.276912] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 23s!
> [iptables-restor:900]

Hm, maintainer no longer at oracle?

Delivery to the following recipient failed permanently:
550 5.1.1 Unknown oracle.com recipient.

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: Linux 4.1.28

[Arkadiusz Miskiewicz]

On Wednesday 20 of July 2016, Arkadiusz Miskiewicz wrote:
> On Friday 15 of July 2016, Thomas Voegtle wrote:
> > On Fri, 15 Jul 2016, Sasha Levin wrote:
> > > On 07/15/2016 07:38 AM, Thomas Voegtle wrote:
> > >> On Wed, 13 Jul 2016, Sasha Levin wrote:
> > >>> I'm announcing the release of the 4.1.28 kernel.
> > >> 
> > >> I have a serious memleak with 4.1.28 (like 20mb/s)
> > >> I stripped down my kernel config and started a bisect, which came to:
> > >> 
> > >> # first bad commit: [c5ad33184354260be6d05de57e46a5498692f6d6]
> > >> mm/swap.c: flush lru pvecs on compound page arrival
> > >> =>
> > >> commit c5ad33184354260be6d05de57e46a5498692f6d6
> > >> Author: Lukasz Odzioba 
> > >> Date:   Fri Jun 24 14:50:01 2016 -0700
> > >> 
> > >> mm/swap.c: flush lru pvecs on compound page arrival
> > >> 
> > >> Reverting this on top 4.1.28 helps. Config attached.
> > > 
> > > Yup, this was reported and a fix is already queued for 4.1.29.
> > 
> > And that one?
> > Happens while trying to start a firewall script with iptables-restore.
> > 
> > 
> > [  180.071999] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
> > [iptables-restor:2338]
> 
> Same here but I don't have actuall trace
> 
> Applying iptables firewall rules...[
> 42.297704] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [iptables-
> restor:900]
> [   70.287999] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s!
> [iptables-restor:900]
> [  102.276912] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 23s!
> [iptables-restor:900]

Hm, maintainer no longer at oracle?

Delivery to the following recipient failed permanently:
550 5.1.1 Unknown oracle.com recipient.

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: Linux 4.1.28

[Arkadiusz Miskiewicz]

On Friday 15 of July 2016, Thomas Voegtle wrote:
> On Fri, 15 Jul 2016, Sasha Levin wrote:
> > On 07/15/2016 07:38 AM, Thomas Voegtle wrote:
> >> On Wed, 13 Jul 2016, Sasha Levin wrote:
> >>> I'm announcing the release of the 4.1.28 kernel.
> >> 
> >> I have a serious memleak with 4.1.28 (like 20mb/s)
> >> I stripped down my kernel config and started a bisect, which came to:
> >> 
> >> # first bad commit: [c5ad33184354260be6d05de57e46a5498692f6d6]
> >> mm/swap.c: flush lru pvecs on compound page arrival
> >> =>
> >> commit c5ad33184354260be6d05de57e46a5498692f6d6
> >> Author: Lukasz Odzioba 
> >> Date:   Fri Jun 24 14:50:01 2016 -0700
> >> 
> >> mm/swap.c: flush lru pvecs on compound page arrival
> >> 
> >> Reverting this on top 4.1.28 helps. Config attached.
> > 
> > Yup, this was reported and a fix is already queued for 4.1.29.
> 
> And that one?
> Happens while trying to start a firewall script with iptables-restore.
> 
> 
> [  180.071999] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
> [iptables-restor:2338]


Same here but I don't have actuall trace

Applying iptables firewall rules...[   
42.297704] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [iptables-
restor:900]
[   70.287999] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! 
[iptables-restor:900]
[  102.276912] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 23s! 
[iptables-restor:900]

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: Linux 4.1.28

[Arkadiusz Miskiewicz]

On Friday 15 of July 2016, Thomas Voegtle wrote:
> On Fri, 15 Jul 2016, Sasha Levin wrote:
> > On 07/15/2016 07:38 AM, Thomas Voegtle wrote:
> >> On Wed, 13 Jul 2016, Sasha Levin wrote:
> >>> I'm announcing the release of the 4.1.28 kernel.
> >> 
> >> I have a serious memleak with 4.1.28 (like 20mb/s)
> >> I stripped down my kernel config and started a bisect, which came to:
> >> 
> >> # first bad commit: [c5ad33184354260be6d05de57e46a5498692f6d6]
> >> mm/swap.c: flush lru pvecs on compound page arrival
> >> =>
> >> commit c5ad33184354260be6d05de57e46a5498692f6d6
> >> Author: Lukasz Odzioba 
> >> Date:   Fri Jun 24 14:50:01 2016 -0700
> >> 
> >> mm/swap.c: flush lru pvecs on compound page arrival
> >> 
> >> Reverting this on top 4.1.28 helps. Config attached.
> > 
> > Yup, this was reported and a fix is already queued for 4.1.29.
> 
> And that one?
> Happens while trying to start a firewall script with iptables-restore.
> 
> 
> [  180.071999] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s!
> [iptables-restor:2338]


Same here but I don't have actuall trace

Applying iptables firewall rules...[   
42.297704] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [iptables-
restor:900]
[   70.287999] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! 
[iptables-restor:900]
[  102.276912] NMI watchdog: BUG: soft lockup - CPU#7 stuck for 23s! 
[iptables-restor:900]

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

On Friday 24 of July 2015, Mathias Nyman wrote:
> On 24.07.2015 14:59, Mathias Nyman wrote:
> > On 22.07.2015 17:12, Arkadiusz Miskiewicz wrote:
> >> On Tuesday 21 of July 2015, Mathias Nyman wrote:
> >>> On 20.07.2015 23:13, Arkadiusz Miskiewicz wrote:
> >>>> On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
> >>>>> Hi.
> >>>>> 
> >>>>> I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some
> >>>>> file from usb storage (sata disk behind sata-usb bridge or pendrive;
> >>>>> hapens in
> >>>> 
> >>>>> both cases) copying process hangs just early after start with:
> >>>> Looks like suspend & resume is enough. Reloading bluetooth firmware
> >>>> done by kernel triggers problem:
> >>>> 
> >>>> [  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
> >>>> [  106.313280] PM: resume of devices complete after 3003.032 msecs
> >>>> [  106.314079] Restarting tasks ... done.
> >>>> [  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
> >>>> [  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file:
> >>>> intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq [  106.398223] xhci_hcd
> >>>> :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
> >>>> ep_index 0 comp_code 1
> > 
> > Thanks for the logs, They show that the error is related to transfer
> > descriptors that wrap around on the endpoint ring buffer by exactly one
> > transfer block.
> > 
> > I don't know yet why this happens, and I might need some help running
> > additional debug patches to solve this. I'll take a more in depth look
> > at the code one more time first.
> 
> I think I found something, The recent ring segment size increase exposed an
> off by one error that has been in the driver for a long time. But you need
> to be unlucky and have your memory pages allocated in a specific order to
> trigger it.
> 
> small fix, looks like this:
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 94416ff..77da8fe 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
> return 0;
> /* offset in TRBs */
> segment_offset = trb - seg->trbs;
> -   if (segment_offset > TRBS_PER_SEGMENT)
> +   if (segment_offset > TRBS_PER_SEGMENT - 1)
> return 0;
> return seg->dma + (segment_offset * sizeof(*trb));
>  }
> 
> 
> Patch attached, could you try it out?

Works fine with this patch, so:

Tested-by: Arkadiusz Miśkiewicz 

Thanks!

ps. please push to stable@, too

> 
> Thanks
> -Mathias

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

On Friday 24 of July 2015, Mathias Nyman wrote:
 On 24.07.2015 14:59, Mathias Nyman wrote:
  On 22.07.2015 17:12, Arkadiusz Miskiewicz wrote:
  On Tuesday 21 of July 2015, Mathias Nyman wrote:
  On 20.07.2015 23:13, Arkadiusz Miskiewicz wrote:
  On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
  Hi.
  
  I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some
  file from usb storage (sata disk behind sata-usb bridge or pendrive;
  hapens in
  
  both cases) copying process hangs just early after start with:
  Looks like suspend  resume is enough. Reloading bluetooth firmware
  done by kernel triggers problem:
  
  [  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
  [  106.313280] PM: resume of devices complete after 3003.032 msecs
  [  106.314079] Restarting tasks ... done.
  [  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
  [  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file:
  intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq [  106.398223] xhci_hcd
  :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
  ep_index 0 comp_code 1
  
  Thanks for the logs, They show that the error is related to transfer
  descriptors that wrap around on the endpoint ring buffer by exactly one
  transfer block.
  
  I don't know yet why this happens, and I might need some help running
  additional debug patches to solve this. I'll take a more in depth look
  at the code one more time first.
 
 I think I found something, The recent ring segment size increase exposed an
 off by one error that has been in the driver for a long time. But you need
 to be unlucky and have your memory pages allocated in a specific order to
 trigger it.
 
 small fix, looks like this:
 
 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index 94416ff..77da8fe 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
 return 0;
 /* offset in TRBs */
 segment_offset = trb - seg-trbs;
 -   if (segment_offset  TRBS_PER_SEGMENT)
 +   if (segment_offset  TRBS_PER_SEGMENT - 1)
 return 0;
 return seg-dma + (segment_offset * sizeof(*trb));
  }
 
 
 Patch attached, could you try it out?

Works fine with this patch, so:

Tested-by: Arkadiusz Miśkiewicz ar...@maven.pl

Thanks!

ps. please push to stable@, too

 
 Thanks
 -Mathias

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

[sorry, resend from different email - vger postmaster team has stupid filters 
in place]

On Tuesday 21 of July 2015, Mathias Nyman wrote:
> On 20.07.2015 23:13, Arkadiusz Miskiewicz wrote:
> > On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
> >> Hi.
> >> 
> >> I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some
> >> file from usb storage (sata disk behind sata-usb bridge or pendrive;
> >> hapens in
> > 
> >> both cases) copying process hangs just early after start with:
> > Looks like suspend & resume is enough. Reloading bluetooth firmware done
> > by kernel triggers problem:
> > 
> > [  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
> > [  106.313280] PM: resume of devices complete after 3003.032 msecs
> > [  106.314079] Restarting tasks ... done.
> > [  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
> > [  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file:
> > intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq [  106.398223] xhci_hcd
> > :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
> > ep_index 0 comp_code 1
> 
> Looks like we get an event for a really old transfer for some reason, it
> should probably be handled already.
> 
> I got a patch that adds more paranoid checks for TRB cancel, which has been
> one major reasons for the "Transfer event TRB DMA ptr not part of current
> TD" Errors. It also adds some logging to show what's went wrong. (patch
> attached, applies on 4.2-rc3) Can you see if it helps?

It doesn't unfortunately. 4.2.0-rc3-00017-gd725e66 + that patch
-> dmesg http://sprunge.us/PDIE

around 91s - after resume from ram bluetooth driver reloads

around 754s - tried to copy data from external usb disk


> If it doesn't, then adding xhci debugging could give us some clue:
> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control

Ok, http://sprunge.us/GiHX

mounted fs around 1347s and started copying; TRB problems were still there but 
file was being copied (in bursts)

> You said 3.19.3 works fine, but 4.0.8 and 4.2-rc2 fail, any chance you
> could bisect it?

Unfortunately some kernels around 3.19 don't even boot (grub says it loads 
initrd and no progress from that) - some commit fixed that but no idea which 
one.

> Thanks
> -Mathias

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

[sorry, resend from different email - vger postmaster team has stupid filters 
in place]

On Tuesday 21 of July 2015, Mathias Nyman wrote:
 On 20.07.2015 23:13, Arkadiusz Miskiewicz wrote:
  On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
  Hi.
  
  I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some
  file from usb storage (sata disk behind sata-usb bridge or pendrive;
  hapens in
  
  both cases) copying process hangs just early after start with:
  Looks like suspend  resume is enough. Reloading bluetooth firmware done
  by kernel triggers problem:
  
  [  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
  [  106.313280] PM: resume of devices complete after 3003.032 msecs
  [  106.314079] Restarting tasks ... done.
  [  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
  [  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file:
  intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq [  106.398223] xhci_hcd
  :00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
  ep_index 0 comp_code 1
 
 Looks like we get an event for a really old transfer for some reason, it
 should probably be handled already.
 
 I got a patch that adds more paranoid checks for TRB cancel, which has been
 one major reasons for the Transfer event TRB DMA ptr not part of current
 TD Errors. It also adds some logging to show what's went wrong. (patch
 attached, applies on 4.2-rc3) Can you see if it helps?

It doesn't unfortunately. 4.2.0-rc3-00017-gd725e66 + that patch
- dmesg http://sprunge.us/PDIE

around 91s - after resume from ram bluetooth driver reloads

around 754s - tried to copy data from external usb disk


 If it doesn't, then adding xhci debugging could give us some clue:
 echo -n 'module xhci_hcd =p'  /sys/kernel/debug/dynamic_debug/control

Ok, http://sprunge.us/GiHX

mounted fs around 1347s and started copying; TRB problems were still there but 
file was being copied (in bursts)

 You said 3.19.3 works fine, but 4.0.8 and 4.2-rc2 fail, any chance you
 could bisect it?

Unfortunately some kernels around 3.19 don't even boot (grub says it loads 
initrd and no progress from that) - some commit fixed that but no idea which 
one.

 Thanks
 -Mathias

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
> Hi.
> 
> I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some file
> from usb storage (sata disk behind sata-usb bridge or pendrive; hapens in
> both cases) copying process hangs just early after start with:

Looks like suspend & resume is enough. Reloading bluetooth firmware done by 
kernel
triggers problem:

[  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
[  106.313280] PM: resume of devices complete after 3003.032 msecs
[  106.314079] Restarting tasks ... done.
[  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
[  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[  106.398223] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.398230] xhci_hcd :00:14.0: Looking for event-dma fffd3000 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.400396] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.400402] xhci_hcd :00:14.0: Looking for event-dma fffd3030 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.402225] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.402228] xhci_hcd :00:14.0: Looking for event-dma fffd3060 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.404401] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.404408] xhci_hcd :00:14.0: Looking for event-dma fffd3090 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.406229] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.406232] xhci_hcd :00:14.0: Looking for event-dma fffd30c0 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.408389] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.408395] xhci_hcd :00:14.0: Looking for event-dma fffd30f0 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.410291] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.410294] xhci_hcd :00:14.0: Looking for event-dma fffd3120 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.412427] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.412433] xhci_hcd :00:14.0: Looking for event-dma fffd3150 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.414315] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.414318] xhci_hcd :00:14.0: Looking for event-dma fffd3180 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0

[...]



http://sprunge.us/IDUh


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
 Hi.
 
 I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some file
 from usb storage (sata disk behind sata-usb bridge or pendrive; hapens in
 both cases) copying process hangs just early after start with:

Looks like suspend  resume is enough. Reloading bluetooth firmware done by 
kernel
triggers problem:

[  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
[  106.313280] PM: resume of devices complete after 3003.032 msecs
[  106.314079] Restarting tasks ... done.
[  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
[  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[  106.398223] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.398230] xhci_hcd :00:14.0: Looking for event-dma fffd3000 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.400396] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.400402] xhci_hcd :00:14.0: Looking for event-dma fffd3030 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.402225] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.402228] xhci_hcd :00:14.0: Looking for event-dma fffd3060 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.404401] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.404408] xhci_hcd :00:14.0: Looking for event-dma fffd3090 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.406229] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.406232] xhci_hcd :00:14.0: Looking for event-dma fffd30c0 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.408389] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.408395] xhci_hcd :00:14.0: Looking for event-dma fffd30f0 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.410291] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.410294] xhci_hcd :00:14.0: Looking for event-dma fffd3120 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.412427] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.412433] xhci_hcd :00:14.0: Looking for event-dma fffd3150 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.414315] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.414318] xhci_hcd :00:14.0: Looking for event-dma fffd3180 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0

[...]



http://sprunge.us/IDUh


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

Hi.

I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some file from
usb storage (sata disk behind sata-usb bridge or pendrive; hapens in both cases)
copying process hangs just early after start with:

[   77.372137] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[   77.388945] usb 2-1: New USB device found, idVendor=1f75, idProduct=0611
[   77.388952] usb 2-1: New USB device strings: Mfr=4, Product=5, SerialNumber=6
[   77.388956] usb 2-1: SerialNumber: 20130514
[   77.402599] usb-storage 2-1:1.0: USB Mass Storage device detected
[   77.403177] scsi host6: usb-storage 2-1:1.0
[   77.403318] usbcore: registered new interface driver usb-storage
[   77.407529] usbcore: registered new interface driver uas
[   78.400954] scsi 6:0:0:0: scsi scan: INQUIRY result too short (5), using 36
[   78.400961] scsi 6:0:0:0: Direct-Access Hitachi  HDS723020BLA642   
PQ: 0 ANSI: 0
[   78.401401] sd 6:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 
TB/1.81 TiB)
[   78.402126] sd 6:0:0:0: [sdb] Write Protect is off
[   78.402130] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[   78.402876] sd 6:0:0:0: [sdb] No Caching mode page found
[   78.402882] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[   78.444310] sd 6:0:0:0: [sdb] Attached SCSI disk
[   85.907972] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: 
(null)
[  113.556376] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  113.556383] xhci_hcd :00:14.0: Looking for event-dma fffa4000 
trb-start fffa5fe0 trb-end fffa6000 seg-start fffa5000 
seg-end fffa5ff0
[  234.236311] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  234.890862] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  234.890869] xhci_hcd :00:14.0: Looking for event-dma fff94000 
trb-start fff95fd0 trb-end fff96000 seg-start fff95000 
seg-end fff95ff0
[  355.339935] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  355.574012] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  355.574018] xhci_hcd :00:14.0: Looking for event-dma fff84000 
trb-start fff85fb0 trb-end fff86000 seg-start fff85000 
seg-end fff85ff0
[  476.430339] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  476.728729] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  476.728738] xhci_hcd :00:14.0: Looking for event-dma fff74000 
trb-start fff75fe0 trb-end fff76000 seg-start fff75000 
seg-end fff75ff0

3.19.3 works fine
4.0.8 fails
4.2.0-rc2-00077-gf760b87 fails

There was some similar thread in march 2015 but the issue there got resolved
by reverting one usb patch, so my issue has to be different (that revert is 
included
in 4.0 final I think).

.config -> http://sprunge.us/bACC
lsusb -> http://sprunge.us/DOWb
dmesg -> http://sprunge.us/UbTF

machine is dell xps 15 9530

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

Hi.

I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some file from
usb storage (sata disk behind sata-usb bridge or pendrive; hapens in both cases)
copying process hangs just early after start with:

[   77.372137] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[   77.388945] usb 2-1: New USB device found, idVendor=1f75, idProduct=0611
[   77.388952] usb 2-1: New USB device strings: Mfr=4, Product=5, SerialNumber=6
[   77.388956] usb 2-1: SerialNumber: 20130514
[   77.402599] usb-storage 2-1:1.0: USB Mass Storage device detected
[   77.403177] scsi host6: usb-storage 2-1:1.0
[   77.403318] usbcore: registered new interface driver usb-storage
[   77.407529] usbcore: registered new interface driver uas
[   78.400954] scsi 6:0:0:0: scsi scan: INQUIRY result too short (5), using 36
[   78.400961] scsi 6:0:0:0: Direct-Access Hitachi  HDS723020BLA642   
PQ: 0 ANSI: 0
[   78.401401] sd 6:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 
TB/1.81 TiB)
[   78.402126] sd 6:0:0:0: [sdb] Write Protect is off
[   78.402130] sd 6:0:0:0: [sdb] Mode Sense: 3b 00 00 00
[   78.402876] sd 6:0:0:0: [sdb] No Caching mode page found
[   78.402882] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[   78.444310] sd 6:0:0:0: [sdb] Attached SCSI disk
[   85.907972] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: 
(null)
[  113.556376] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  113.556383] xhci_hcd :00:14.0: Looking for event-dma fffa4000 
trb-start fffa5fe0 trb-end fffa6000 seg-start fffa5000 
seg-end fffa5ff0
[  234.236311] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  234.890862] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  234.890869] xhci_hcd :00:14.0: Looking for event-dma fff94000 
trb-start fff95fd0 trb-end fff96000 seg-start fff95000 
seg-end fff95ff0
[  355.339935] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  355.574012] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  355.574018] xhci_hcd :00:14.0: Looking for event-dma fff84000 
trb-start fff85fb0 trb-end fff86000 seg-start fff85000 
seg-end fff85ff0
[  476.430339] usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
[  476.728729] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 2 comp_code 1
[  476.728738] xhci_hcd :00:14.0: Looking for event-dma fff74000 
trb-start fff75fe0 trb-end fff76000 seg-start fff75000 
seg-end fff75ff0

3.19.3 works fine
4.0.8 fails
4.2.0-rc2-00077-gf760b87 fails

There was some similar thread in march 2015 but the issue there got resolved
by reverting one usb patch, so my issue has to be different (that revert is 
included
in 4.0 final I think).

.config - http://sprunge.us/bACC
lsusb - http://sprunge.us/DOWb
dmesg - http://sprunge.us/UbTF

machine is dell xps 15 9530

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Bug 3.14.17] inconsistent lock state

[Arkadiusz Miskiewicz]

On Sunday 24 of August 2014, Linus Torvalds wrote:
> On Sun, Aug 24, 2014 at 4:28 AM, Knut Petersen
> 
>  wrote:
> > Since months the postmaster wantonly blocks all mail traffic from the
> > biggest german ISP t-online.de to all vger.kernel.org mailing lists,
> > therefore I could not cc lkml.
> 
> Hmm.

What is worse postmasters attitude is like this:

"We are under no obligation to explain why you were banned nor to remove
the ban.

If you don't like this, you can run your own list server and on it determine
your own set of policies."

ps. that was citation from vger postmaster David Miller

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

Re: [Bug 3.14.17] inconsistent lock state

[Arkadiusz Miskiewicz]

On Sunday 24 of August 2014, Linus Torvalds wrote:
 On Sun, Aug 24, 2014 at 4:28 AM, Knut Petersen
 
 knut_peter...@t-online.de wrote:
  Since months the postmaster wantonly blocks all mail traffic from the
  biggest german ISP t-online.de to all vger.kernel.org mailing lists,
  therefore I could not cc lkml.
 
 Hmm.

What is worse postmasters attitude is like this:

We are under no obligation to explain why you were banned nor to remove
the ban.

If you don't like this, you can run your own list server and on it determine
your own set of policies.

ps. that was citation from vger postmaster David Miller

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] vt: disable console blanking by default

[Arkadiusz Miskiewicz]

On Wednesday 25 of June 2014, One Thousand Gnomes wrote:
> On Wed, 18 Jun 2014 11:27:31 +0200
> 
> Tomasz Torcz  wrote:
> > >From ea7cf47e3230eda63aa6c46092719437f9bbae8e Mon Sep 17 00:00:00 2001
> > 
> > From: Tomasz Torcz 
> > Date: Wed, 18 Jun 2014 11:18:06 +0200
> > Subject: [PATCH] vt: disable console blanking by default
> > 
> >   Remove default 10 minute blank interval. Instead: never blank by
> >   default.
> >   "Screensaving" is no longer useful.  Today it only provides
> >   obstacle when interacting with text console, especially through
> >   remote lights-out management solutions.
> 
> Screensaving is extremely useful as is power management, and power prices
> are going up not down. We don't customise the upstream kernel just
> because J Random User happens to want his defaults.
> 
> There are a couple of things you can sensibly do
> 
> 1. Just turn it off in software. It's run time configurable via setterm
> 
> 2. If you have a reliable way of detecting the presence of a remote
> console device and that device supports reporting when a connection is
> made/broken you could submit a patch to make it unblank on connect.

3. unblank & disable blanking on any oops? (probably problematic)

Anyway I dislike blanking here, too.

> Alan


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

Re: [PATCH] vt: disable console blanking by default

[Arkadiusz Miskiewicz]

On Wednesday 25 of June 2014, One Thousand Gnomes wrote:
 On Wed, 18 Jun 2014 11:27:31 +0200
 
 Tomasz Torcz to...@pipebreaker.pl wrote:
  From ea7cf47e3230eda63aa6c46092719437f9bbae8e Mon Sep 17 00:00:00 2001
  
  From: Tomasz Torcz to...@pipebreaker.pl
  Date: Wed, 18 Jun 2014 11:18:06 +0200
  Subject: [PATCH] vt: disable console blanking by default
  
Remove default 10 minute blank interval. Instead: never blank by
default.
Screensaving is no longer useful.  Today it only provides
obstacle when interacting with text console, especially through
remote lights-out management solutions.
 
 Screensaving is extremely useful as is power management, and power prices
 are going up not down. We don't customise the upstream kernel just
 because J Random User happens to want his defaults.
 
 There are a couple of things you can sensibly do
 
 1. Just turn it off in software. It's run time configurable via setterm
 
 2. If you have a reliable way of detecting the presence of a remote
 console device and that device supports reporting when a connection is
 made/broken you could submit a patch to make it unblank on connect.

3. unblank  disable blanking on any oops? (probably problematic)

Anyway I dislike blanking here, too.

 Alan


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Support for netconsole as default tty/console?

[Arkadiusz Miskiewicz]

On Monday 31 of March 2014, One Thousand Gnomes wrote:
> On Sat, 29 Mar 2014 15:54:24 +0100
> 
> Andreas Schwab  wrote:
> > Struan Bartlett  writes:
> > > Adding console=netconsole to the command line does not appear to have
> > > the desired effect. I am not sure if this is because netconsole,
> > > unlike the serial console, does not provide a tty. Can anyone advise
> > > if this understanding is correct? If so, is there an independent
> > > solution to this problem?
> > 
> > It should not be hard to add a tty driver to netconsole, there are many
> > examples to borrow from.
> 
> Samo Pogacnik added a generic solution a few years ago. The ttyprintk
> driver provides you with a tty/console whose 'hardware' is printk and
> thus whatever system log device you are using.

Is there a way to get two devices working as console? For example I would like 
to have console on tty0 and on netconsole at the same time. Right now only 
one, last console gets all userspace messages.

> Alan

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

Re: Support for netconsole as default tty/console?

[Arkadiusz Miskiewicz]

On Monday 31 of March 2014, One Thousand Gnomes wrote:
 On Sat, 29 Mar 2014 15:54:24 +0100
 
 Andreas Schwab sch...@linux-m68k.org wrote:
  Struan Bartlett struan.bartl...@gmail.com writes:
   Adding console=netconsole to the command line does not appear to have
   the desired effect. I am not sure if this is because netconsole,
   unlike the serial console, does not provide a tty. Can anyone advise
   if this understanding is correct? If so, is there an independent
   solution to this problem?
  
  It should not be hard to add a tty driver to netconsole, there are many
  examples to borrow from.
 
 Samo Pogacnik added a generic solution a few years ago. The ttyprintk
 driver provides you with a tty/console whose 'hardware' is printk and
 thus whatever system log device you are using.

Is there a way to get two devices working as console? For example I would like 
to have console on tty0 and on netconsole at the same time. Right now only 
one, last console gets all userspace messages.

 Alan

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel bugzilla #64531: intel microcode information

[Arkadiusz Miskiewicz]

On Thursday 07 of November 2013, Randy Dunlap wrote:
> Re: https://bugzilla.kernel.org/show_bug.cgi?id=64531
> 
> 
> arch/x86/Kconfig line 1053 (+/-), help section in CONFIG_MICROCODE_INTEL,
> says:
> 
> For latest news and information on obtaining all the required
> Intel ingredients for this driver, check:
> 
> 
> ==> 404  Page not found
> 
> 
> Is there a good replacement for this information or should we just
> delete that help text?

For downloading
 http://downloadcenter.intel.com/ -> search for "processor microcode data 
file"


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

Re: kernel bugzilla #64531: intel microcode information

[Arkadiusz Miskiewicz]

On Thursday 07 of November 2013, Randy Dunlap wrote:
 Re: https://bugzilla.kernel.org/show_bug.cgi?id=64531
 
 
 arch/x86/Kconfig line 1053 (+/-), help section in CONFIG_MICROCODE_INTEL,
 says:
 
 For latest news and information on obtaining all the required
 Intel ingredients for this driver, check:
 http://www.urbanmyth.org/microcode/
 
 == 404  Page not found
 
 
 Is there a good replacement for this information or should we just
 delete that help text?

For downloading
 http://downloadcenter.intel.com/ - search for processor microcode data 
file


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

[Arkadiusz Miskiewicz]

On Tuesday 03 of September 2013, Arkadiusz Miskiewicz wrote:
> On Sunday 18 of August 2013, Margarita Manterola wrote:
> > Hi,
> > 
> > On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek  wrote:
> > >> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> > >> index 4bf0fc0..2ba7f4e 100644
> > >> --- a/drivers/tty/n_tty.c
> > >> +++ b/drivers/tty/n_tty.c
> > >> @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
> > >> 
> > >>  * characters will be beeped.
> > >>  */
> > >> 
> > >> if (left <= 0)
> > >> 
> > >> -   left = ldata->icanon && !ldata->canon_data;
> > >> +   if (waitqueue_active(>read_wait))
> > >> +   left = ldata->icanon && !ldata->canon_data;
> > >> 
> > >> old_left = tty->receive_room;
> > >> tty->receive_room = left;
> > > 
> > > Was this applied? You may want to cc rjw... it is a regression, it is
> > > not pretty, and it is something I blieve I hit but thought it was some
> > > kind of "X weirdness".
> > 
> > There were no replies to the previous mail asking for comments, and as
> > far as I can see this has not been applied. I don't know who rjw is,
> > could you be a bit more explicit, please?
> 

Hi

Was just going over bug-readline and lkml archives and found no continuation 
of this. 

There was a patch proposed but didn't get applied. 
https://lkml.org/lkml/2013/8/17/31
Maybe it only needs proper patch submission?

Looking from bug-readline archives debugging it took huge amount of work and 
would be sad that all that ended up being wasted.

Whole thread if someone lost it https://lkml.org/lkml/2013/7/25/205

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

Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

[Arkadiusz Miskiewicz]

On Tuesday 03 of September 2013, Arkadiusz Miskiewicz wrote:
 On Sunday 18 of August 2013, Margarita Manterola wrote:
  Hi,
  
  On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek pa...@ucw.cz wrote:
   diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
   index 4bf0fc0..2ba7f4e 100644
   --- a/drivers/tty/n_tty.c
   +++ b/drivers/tty/n_tty.c
   @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
   
* characters will be beeped.
*/
   
   if (left = 0)
   
   -   left = ldata-icanon  !ldata-canon_data;
   +   if (waitqueue_active(tty-read_wait))
   +   left = ldata-icanon  !ldata-canon_data;
   
   old_left = tty-receive_room;
   tty-receive_room = left;
   
   Was this applied? You may want to cc rjw... it is a regression, it is
   not pretty, and it is something I blieve I hit but thought it was some
   kind of X weirdness.
  
  There were no replies to the previous mail asking for comments, and as
  far as I can see this has not been applied. I don't know who rjw is,
  could you be a bit more explicit, please?
 

Hi

Was just going over bug-readline and lkml archives and found no continuation 
of this. 

There was a patch proposed but didn't get applied. 
https://lkml.org/lkml/2013/8/17/31
Maybe it only needs proper patch submission?

Looking from bug-readline archives debugging it took huge amount of work and 
would be sad that all that ended up being wasted.

Whole thread if someone lost it https://lkml.org/lkml/2013/7/25/205

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

[Arkadiusz Miskiewicz]

On Sunday 18 of August 2013, Margarita Manterola wrote:
> Hi,
> 
> On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek  wrote:
> >> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
> >> index 4bf0fc0..2ba7f4e 100644
> >> --- a/drivers/tty/n_tty.c
> >> +++ b/drivers/tty/n_tty.c
> >> @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
> >> 
> >>  * characters will be beeped.
> >>  */
> >> 
> >> if (left <= 0)
> >> 
> >> -   left = ldata->icanon && !ldata->canon_data;
> >> +   if (waitqueue_active(>read_wait))
> >> +   left = ldata->icanon && !ldata->canon_data;
> >> 
> >> old_left = tty->receive_room;
> >> tty->receive_room = left;
> > 
> > Was this applied? You may want to cc rjw... it is a regression, it is
> > not pretty, and it is something I blieve I hit but thought it was some
> > kind of "X weirdness".
> 
> There were no replies to the previous mail asking for comments, and as
> far as I can see this has not been applied. I don't know who rjw is,
> could you be a bit more explicit, please?

Hi.

Was there some kind of continuation of this thread or the thing died 
completly?

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

Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

[Arkadiusz Miskiewicz]

On Sunday 18 of August 2013, Margarita Manterola wrote:
 Hi,
 
 On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek pa...@ucw.cz wrote:
  diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
  index 4bf0fc0..2ba7f4e 100644
  --- a/drivers/tty/n_tty.c
  +++ b/drivers/tty/n_tty.c
  @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
  
   * characters will be beeped.
   */
  
  if (left = 0)
  
  -   left = ldata-icanon  !ldata-canon_data;
  +   if (waitqueue_active(tty-read_wait))
  +   left = ldata-icanon  !ldata-canon_data;
  
  old_left = tty-receive_room;
  tty-receive_room = left;
  
  Was this applied? You may want to cc rjw... it is a regression, it is
  not pretty, and it is something I blieve I hit but thought it was some
  kind of X weirdness.
 
 There were no replies to the previous mail asking for comments, and as
 far as I can see this has not been applied. I don't know who rjw is,
 could you be a bit more explicit, please?

Hi.

Was there some kind of continuation of this thread or the thing died 
completly?

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9] irq: add quirk for broken interrupt remapping on 55XX chipsets

[Arkadiusz Miskiewicz]

On Tuesday 16 of April 2013, Neil Horman wrote:
> A few years back intel published a spec update:
> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chi
> pset-ioh-specification-update.pdf
> 
> For the 5520 and 5500 chipsets which contained an errata (specificially
> errata 53), which noted that these chipsets can't properly do interrupt
> remapping, and as a result the recommend that interrupt remapping be
> disabled in bios.  While many vendors have a bios update to do exactly
> that, not all do, and of course not all users update their bios to a level
> that corrects the problem.  As a result, occasionally interrupts can
> arrive at a cpu even after affinity for that interrupt has be moved,
> leading to lost or spurrious interrupts (usually characterized by the
> message:
> kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)
> 
> There have been several incidents recently of people seeing this error, and
> investigation has shown that they have system for which their BIOS level is
> such that this feature was not properly turned off.  As such, it would be
> good to give them a reminder that their systems are vulnurable to this
> problem.  For details of those that reported the problem, please see:
> https://bugzilla.redhat.com/show_bug.cgi?id=887006

Tested-by: Arkadiusz Miśkiewicz 

(on top of 3.7.10 kernel)

Stack trace looks useless for me in this case but according changelog this was 
already discussed.

[0.137512] Freeing SMP alternatives: 20k freed
[0.143539] ACPI: Core revision 20120913
[0.156067] dmar: Host address width 40
[0.160440] dmar: DRHD base: 0x00fe71 flags: 0x1
[0.166467] dmar: IOMMU 0: reg_base_addr fe71 ver 1:0 cap 
c90780106f0462 ecap f020f7
[0.175618] dmar: RMRR base: 0x008f62f000 end: 0x008f631fff
[0.182705] dmar: RMRR base: 0x008f61a000 end: 0x008f61afff
[0.189792] dmar: RMRR base: 0x008f617000 end: 0x008f617fff
[0.196871] dmar: RMRR base: 0x008f614000 end: 0x008f614fff
[0.203960] dmar: RMRR base: 0x008f611000 end: 0x008f611fff
[0.211047] dmar: RMRR base: 0x008f60e000 end: 0x008f60efff
[0.218135] dmar: RMRR base: 0x008f60b000 end: 0x008f60bfff
[0.225222] dmar: RMRR base: 0x008f608000 end: 0x008f608fff
[0.232309] dmar: RMRR base: 0x008f605000 end: 0x008f605fff
[0.239388] dmar: ATSR flags: 0x0
[0.243273] [ cut here ]
[0.248515] WARNING: at 
/home/users/arekm/rpm/BUILD/kernel-3.7.10/linux-3.7/drivers/iommu/intel_irq_remapping.c:518
 
intel_irq_remapping_supported+0x37/0x7
a()
[0.264358] Hardware name: S5500WB
[0.268238] This system BIOS has enabled interrupt remapping
on a chipset that contains an erratum making that
feature unstable.  To maintain system stability
interrupt remapping is being disabled.  Please
contact your BIOS vendor for an update
[0.298811] Modules linked in:
[0.302373] Pid: 1, comm: swapper/0 xid: #0 Not tainted 3.7.10-6 #1
[0.309453] Call Trace:
[0.312270]  [] warn_slowpath_common+0x7a/0xb0
[0.319061]  [] warn_slowpath_fmt_taint+0x3a/0x40
[0.326143]  [] intel_irq_remapping_supported+0x37/0x7a
[0.333810]  [] irq_remapping_supported+0x26/0x30
[0.340893]  [] enable_IR+0x9/0x3e
[0.346521]  [] enable_IR_x2apic+0xa0/0x1e3
[0.353024]  [] ? set_cpu_sibling_map+0x415/0x435
[0.360108]  [] default_setup_apic_routing+0x12/0x6b
[0.367483]  [] native_smp_prepare_cpus+0x2e7/0x336
[0.374761]  [] kernel_init_freeable+0x89/0x1c4
[0.381652]  [] ? rest_init+0x70/0x70
[0.387570]  [] kernel_init+0x9/0x100
[0.393489]  [] ret_from_fork+0x7c/0xb0
[0.399602]  [] ? rest_init+0x70/0x70
[0.405524] ---[ end trace bf40f410b44b3726 ]---
[0.410830] Switched APIC routing to physical flat.
[0.416872] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[0.456602] smpboot: CPU0: Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz 
(fam: 06, model: 1a, stepping: 04)
[0.573650] Performance Events: PEBS fmt1+, 16-deep LBR, Nehalem events, 
Intel PMU driver.
[0.583265] perf_event_intel: CPU erratum AAJ80 worked around


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

Re: [PATCH v9] irq: add quirk for broken interrupt remapping on 55XX chipsets

[Arkadiusz Miskiewicz]

On Tuesday 16 of April 2013, Neil Horman wrote:
 A few years back intel published a spec update:
 http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chi
 pset-ioh-specification-update.pdf
 
 For the 5520 and 5500 chipsets which contained an errata (specificially
 errata 53), which noted that these chipsets can't properly do interrupt
 remapping, and as a result the recommend that interrupt remapping be
 disabled in bios.  While many vendors have a bios update to do exactly
 that, not all do, and of course not all users update their bios to a level
 that corrects the problem.  As a result, occasionally interrupts can
 arrive at a cpu even after affinity for that interrupt has be moved,
 leading to lost or spurrious interrupts (usually characterized by the
 message:
 kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)
 
 There have been several incidents recently of people seeing this error, and
 investigation has shown that they have system for which their BIOS level is
 such that this feature was not properly turned off.  As such, it would be
 good to give them a reminder that their systems are vulnurable to this
 problem.  For details of those that reported the problem, please see:
 https://bugzilla.redhat.com/show_bug.cgi?id=887006

Tested-by: Arkadiusz Miśkiewicz ar...@maven.pl

(on top of 3.7.10 kernel)

Stack trace looks useless for me in this case but according changelog this was 
already discussed.

[0.137512] Freeing SMP alternatives: 20k freed
[0.143539] ACPI: Core revision 20120913
[0.156067] dmar: Host address width 40
[0.160440] dmar: DRHD base: 0x00fe71 flags: 0x1
[0.166467] dmar: IOMMU 0: reg_base_addr fe71 ver 1:0 cap 
c90780106f0462 ecap f020f7
[0.175618] dmar: RMRR base: 0x008f62f000 end: 0x008f631fff
[0.182705] dmar: RMRR base: 0x008f61a000 end: 0x008f61afff
[0.189792] dmar: RMRR base: 0x008f617000 end: 0x008f617fff
[0.196871] dmar: RMRR base: 0x008f614000 end: 0x008f614fff
[0.203960] dmar: RMRR base: 0x008f611000 end: 0x008f611fff
[0.211047] dmar: RMRR base: 0x008f60e000 end: 0x008f60efff
[0.218135] dmar: RMRR base: 0x008f60b000 end: 0x008f60bfff
[0.225222] dmar: RMRR base: 0x008f608000 end: 0x008f608fff
[0.232309] dmar: RMRR base: 0x008f605000 end: 0x008f605fff
[0.239388] dmar: ATSR flags: 0x0
[0.243273] [ cut here ]
[0.248515] WARNING: at 
/home/users/arekm/rpm/BUILD/kernel-3.7.10/linux-3.7/drivers/iommu/intel_irq_remapping.c:518
 
intel_irq_remapping_supported+0x37/0x7
a()
[0.264358] Hardware name: S5500WB
[0.268238] This system BIOS has enabled interrupt remapping
on a chipset that contains an erratum making that
feature unstable.  To maintain system stability
interrupt remapping is being disabled.  Please
contact your BIOS vendor for an update
[0.298811] Modules linked in:
[0.302373] Pid: 1, comm: swapper/0 xid: #0 Not tainted 3.7.10-6 #1
[0.309453] Call Trace:
[0.312270]  [8105182a] warn_slowpath_common+0x7a/0xb0
[0.319061]  [810518ba] warn_slowpath_fmt_taint+0x3a/0x40
[0.326143]  [818e8371] intel_irq_remapping_supported+0x37/0x7a
[0.333810]  [813b7226] irq_remapping_supported+0x26/0x30
[0.340893]  [818bd1be] enable_IR+0x9/0x3e
[0.346521]  [818bd558] enable_IR_x2apic+0xa0/0x1e3
[0.353024]  [814cfdc4] ? set_cpu_sibling_map+0x415/0x435
[0.360108]  [818bf47a] default_setup_apic_routing+0x12/0x6b
[0.367483]  [818bb30b] native_smp_prepare_cpus+0x2e7/0x336
[0.374761]  [818abcd5] kernel_init_freeable+0x89/0x1c4
[0.381652]  [814b9380] ? rest_init+0x70/0x70
[0.387570]  [814b9389] kernel_init+0x9/0x100
[0.393489]  [814e8d7c] ret_from_fork+0x7c/0xb0
[0.399602]  [814b9380] ? rest_init+0x70/0x70
[0.405524] ---[ end trace bf40f410b44b3726 ]---
[0.410830] Switched APIC routing to physical flat.
[0.416872] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[0.456602] smpboot: CPU0: Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz 
(fam: 06, model: 1a, stepping: 04)
[0.573650] Performance Events: PEBS fmt1+, 16-deep LBR, Nehalem events, 
Intel PMU driver.
[0.583265] perf_event_intel: CPU erratum AAJ80 worked around


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] watchdog: Fix race condition in registration code

[Arkadiusz Miskiewicz]

On Saturday 06 of April 2013, Guenter Roeck wrote:
> A race condition exists when registering the first watchdog device.
> Sequence of events:
> 
> - watchdog_register_device calls watchdog_dev_register
> - watchdog_dev_register creates the watchdog misc device by calling
>   misc_register.
>   At that time, the matching character device (/dev/watchdog0) does not yet
>   exist, and old_wdd is not set either.
> - Userspace gets an event and opens /dev/watchdog
> - watchdog_open is called and sets sets wdd = old_wdd, which is still NULL,
>   and tries to dereference it. This causes the kernel to panic.
> 
> Seen with systemd trying to open /dev/watchdog immediately after
> it was created.
> 
> Reported-by: Arkadiusz Miskiewicz 

Please use
Reported-by: Arkadiusz Miśkiewicz 

I have to use gmail address because maven.pl domain is blocked due to some 
unknown, secret reason and vger.kernel.org postmasters (Dave M etc) are less 
than helpful:

"We are under no obligation to explain why you were banned nor to remove
the ban.

If you don't like this, you can run your own list server and on it determine
your own set of policies."


> Signed-off-by: Guenter Roeck 
> ---
> Arkadiusz,
> 
> would be great if you can test this in your system.

Did few reboots without oops but this test isn't reliable. Previously I wasn't 
able to reproduce this on demand. It just happens sometime. If any problem 
popup I'll let you know.

So for now
Tested-by: Arkadiusz Miśkiewicz 

> 
>  drivers/watchdog/watchdog_dev.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/watchdog_dev.c
> b/drivers/watchdog/watchdog_dev.c index 08b48bb..faf4e18 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -523,6 +523,7 @@ int watchdog_dev_register(struct watchdog_device
> *watchdog) int err, devno;
> 
>   if (watchdog->id == 0) {
> + old_wdd = watchdog;
>   watchdog_miscdev.parent = watchdog->parent;
>   err = misc_register(_miscdev);
>   if (err != 0) {
> @@ -531,9 +532,9 @@ int watchdog_dev_register(struct watchdog_device
> *watchdog) if (err == -EBUSY)
>   pr_err("%s: a legacy watchdog module is 
> probably present.\n",
>   watchdog->info->identity);
> + old_wdd = NULL;
>   return err;
>   }
> - old_wdd = watchdog;
>   }
> 
>   /* Fill in the data structures */


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

Re: [PATCH] watchdog: Fix race condition in registration code

[Arkadiusz Miskiewicz]

On Saturday 06 of April 2013, Guenter Roeck wrote:
 A race condition exists when registering the first watchdog device.
 Sequence of events:
 
 - watchdog_register_device calls watchdog_dev_register
 - watchdog_dev_register creates the watchdog misc device by calling
   misc_register.
   At that time, the matching character device (/dev/watchdog0) does not yet
   exist, and old_wdd is not set either.
 - Userspace gets an event and opens /dev/watchdog
 - watchdog_open is called and sets sets wdd = old_wdd, which is still NULL,
   and tries to dereference it. This causes the kernel to panic.
 
 Seen with systemd trying to open /dev/watchdog immediately after
 it was created.
 
 Reported-by: Arkadiusz Miskiewicz a.miskiew...@gmail.com

Please use
Reported-by: Arkadiusz Miśkiewicz ar...@maven.pl

I have to use gmail address because maven.pl domain is blocked due to some 
unknown, secret reason and vger.kernel.org postmasters (Dave M etc) are less 
than helpful:

We are under no obligation to explain why you were banned nor to remove
the ban.

If you don't like this, you can run your own list server and on it determine
your own set of policies.


 Signed-off-by: Guenter Roeck li...@roeck-us.net
 ---
 Arkadiusz,
 
 would be great if you can test this in your system.

Did few reboots without oops but this test isn't reliable. Previously I wasn't 
able to reproduce this on demand. It just happens sometime. If any problem 
popup I'll let you know.

So for now
Tested-by: Arkadiusz Miśkiewicz ar...@maven.pl

 
  drivers/watchdog/watchdog_dev.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/watchdog/watchdog_dev.c
 b/drivers/watchdog/watchdog_dev.c index 08b48bb..faf4e18 100644
 --- a/drivers/watchdog/watchdog_dev.c
 +++ b/drivers/watchdog/watchdog_dev.c
 @@ -523,6 +523,7 @@ int watchdog_dev_register(struct watchdog_device
 *watchdog) int err, devno;
 
   if (watchdog-id == 0) {
 + old_wdd = watchdog;
   watchdog_miscdev.parent = watchdog-parent;
   err = misc_register(watchdog_miscdev);
   if (err != 0) {
 @@ -531,9 +532,9 @@ int watchdog_dev_register(struct watchdog_device
 *watchdog) if (err == -EBUSY)
   pr_err(%s: a legacy watchdog module is 
 probably present.\n,
   watchdog-info-identity);
 + old_wdd = NULL;
   return err;
   }
 - old_wdd = watchdog;
   }
 
   /* Fill in the data structures */


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.8.3 and 3.9git occasional watchdog oops

[Arkadiusz Miskiewicz]

On Thursday 14 of March 2013, Arkadiusz Miśkiewicz wrote:
> Hi.
> 
> Just hit watchdog related oops in 3.8.3 kernel. Unfortunately photos only.
> 
> http://ixion.pld-linux.org/~arekm/watchdog-oops-3.8.3/IMG_8942.JPG
> http://ixion.pld-linux.org/~arekm/watchdog-oops-3.8.3/IMG_8941.JPG

3.9git from today isn't any better unfortunately:

http://ixion.pld-linux.org/~arekm/watchdog-oops-3.9git.jpg

> 
> oops started after I enabled systemd watchdog functionality. Cannot
> reproduce easily.
> 
> watchdog here (thinkpad t400) is:
>  iTCO_wdt: Found a ICH9M-E TCO device (Version=2, TCOBASE=0x1060)


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

Re: 3.8.3 and 3.9git occasional watchdog oops

[Arkadiusz Miskiewicz]

On Thursday 14 of March 2013, Arkadiusz Miśkiewicz wrote:
 Hi.
 
 Just hit watchdog related oops in 3.8.3 kernel. Unfortunately photos only.
 
 http://ixion.pld-linux.org/~arekm/watchdog-oops-3.8.3/IMG_8942.JPG
 http://ixion.pld-linux.org/~arekm/watchdog-oops-3.8.3/IMG_8941.JPG

3.9git from today isn't any better unfortunately:

http://ixion.pld-linux.org/~arekm/watchdog-oops-3.9git.jpg

 
 oops started after I enabled systemd watchdog functionality. Cannot
 reproduce easily.
 
 watchdog here (thinkpad t400) is:
  iTCO_wdt: Found a ICH9M-E TCO device (Version=2, TCOBASE=0x1060)


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

[Arkadiusz Miskiewicz]

On Sunday 17 of March 2013, Daniel Vetter wrote:
> On Sat, Mar 16, 2013 at 11:35 AM, Arkadiusz Miskiewicz
> 
>  wrote:
> > On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
> >> Hello.
> > 
> >> After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
> > More people hits this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=922304
> > https://bugs.archlinux.org/task/34327
> > (seems always GM45 gpu in these reports)
> > 
> > archlinux people also noticed that xrandr reports VGA1 as connected
> > (while in reality nothing is connected to VGA1)
> 
> Can you please test whether 3.9-rc kernels are affected, too? 

3.9.0-rc2-00341-g0863702

works fine here

[0.349462] [drm] Initialized drm 1.1.0 20060810
[0.349566] [drm] radeon kernel modesetting enabled.
[0.350049] [drm] Memory usable by graphics device = 2048M
[0.350110] i915 :00:02.0: setting latency timer to 64
[0.374161] i915 :00:02.0: irq 47 for MSI/MSI-X
[0.374170] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.374229] [drm] Driver supports precise vblank timestamp query.
[0.436916] fbcon: inteldrmfb (fb0) is primary device
[0.983961] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[0.983996] i915 :00:02.0: registered panic notifier
[0.986191] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 
0

xrandr reports VGA-1 as disconnected properly

> We need
> to know this since stable rules mandate that a regression is fixed on
> upstream first. Once that's figured out we can backport a fix (if
> 3.9-rc works) or start working on a fix for 3.8-rc kernels first and
> backport afterwards.
> 
> Thanks, Daniel


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

Re: 3.8.2-3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

[Arkadiusz Miskiewicz]

On Sunday 17 of March 2013, Daniel Vetter wrote:
 On Sat, Mar 16, 2013 at 11:35 AM, Arkadiusz Miskiewicz
 
 a.miskiew...@gmail.com wrote:
  On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
  Hello.
  
  After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
  More people hits this:
  https://bugzilla.redhat.com/show_bug.cgi?id=922304
  https://bugs.archlinux.org/task/34327
  (seems always GM45 gpu in these reports)
  
  archlinux people also noticed that xrandr reports VGA1 as connected
  (while in reality nothing is connected to VGA1)
 
 Can you please test whether 3.9-rc kernels are affected, too? 

3.9.0-rc2-00341-g0863702

works fine here

[0.349462] [drm] Initialized drm 1.1.0 20060810
[0.349566] [drm] radeon kernel modesetting enabled.
[0.350049] [drm] Memory usable by graphics device = 2048M
[0.350110] i915 :00:02.0: setting latency timer to 64
[0.374161] i915 :00:02.0: irq 47 for MSI/MSI-X
[0.374170] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.374229] [drm] Driver supports precise vblank timestamp query.
[0.436916] fbcon: inteldrmfb (fb0) is primary device
[0.983961] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[0.983996] i915 :00:02.0: registered panic notifier
[0.986191] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 
0

xrandr reports VGA-1 as disconnected properly

 We need
 to know this since stable rules mandate that a regression is fixed on
 upstream first. Once that's figured out we can backport a fix (if
 3.9-rc works) or start working on a fix for 3.8-rc kernels first and
 backport afterwards.
 
 Thanks, Daniel


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

[Arkadiusz Miskiewicz]

On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
> Hello.
> 
> After upgrading from 3.8.2 to 3.8.3 I'm getting regression :

More people hits this:
https://bugzilla.redhat.com/show_bug.cgi?id=922304
https://bugs.archlinux.org/task/34327
(seems always GM45 gpu in these reports)

archlinux people also noticed that xrandr reports VGA1 as connected (while in 
reality nothing is connected to VGA1)

[arekm@t400 ~]$ more xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 32767 x 32767
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm 
x 190mm
   1440x900   60.0*+   50.0  
   1024x768   60.0  
   800x60060.3 56.2  
   640x48059.9  
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1024x768   60.0* 
   800x60060.3 56.2  
   848x48060.0  
   640x48059.9  
DP1 disconnected (normal left inverted right x axis y axis)

[arekm@t400 ~]$ xrandr --output VGA --mode 1440x900
warning: output VGA not found; ignoring


Normally this looks like:
[arekm@t400 ~]$ more xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 32767 x 32767  
 
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm 
x 190mm
   1440x900   60.0*+   50.0 
 
   1024x768   60.0  
 
   800x60060.3 56.2  
   640x48059.9  
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)

> 
> diff:
>   [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>   [drm] Driver supports precise vblank timestamp query.
>   vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem + [drm]
> GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
> fbcon: inteldrmfb (fb0) is primary device
> - Console: switching to colour frame buffer device 180x56
> + Console: switching to colour frame buffer device 128x48
>   i915 :00:02.0: fb0: inteldrmfb frame buffer device
>   i915 :00:02.0: registered panic notifier
>   acpi device:01: registered as cooling_device0
> 
> console becomes weird, ends up in 2/3 of screen, X when starts gets tiny
> fonts etc.
> 
> Machine is Thinkpad T400 with gm45 GPU
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series
> Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00
> [VGA controller]) Subsystem: Lenovo Device [17aa:2112]
> 
> Reverting bisected commit from 3.8.3 fixes the problem
> 
> 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
> commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
> Author: Daniel Vetter 
> Date:   Sat Dec 1 21:03:22 2012 +0100
> 
> drm/i915: reorder setup sequence to have irqs for output setup
> 
> commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.
> 
> Otherwise the new irq-driven gmbus and dp aux code won't work
> that well. Noticed since the dp aux code doesn't have an automatic
> fallback with a timeout (since the hw provides for that already).
> 
> v2: Simple move drm_irq_install before intel_modeset_gem_init, as
> suggested by Ben Widawsky.
> 
> v3: Now that interrupts are enabled before all connectors are fully
> set up, we might fall over serving a HPD interrupt while things are
> still being set up. Instead of jumping through massive hoops and
> complicating the code with a separate hpd irq enable step, simply
> block out the hotplug work item from doing anything until things are
> in place.
> 
> v4: Actually, we can enable hotplug processing only after the fbdev is
> fully set up, since we call down into the fbdev from the hotplug work
> functions. So stick the hpd enabling right next to the poll helper
> initialization.
> 
> v5: We need to enable irqs before intel_modeset_init, since that
> function sets up the outputs.
> 
> v6: Fixup cleanup sequence, too.
> 
> Reviewed-by: Imre Deak 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Greg Kroah-Hartman 
> 
> :04 04 26e83b14e8d49da8c451dc2c837646a337a79085
> :fa2cbfcf159808ce188675115888242245e4e69d M  drivers
> 
> relevant dmesg:
> 
>  [drm] Initialized drm 1.1.0 20060810
>  [drm] radeon defaulting to userspace modesetting.
>  i915 :00:02.0: setting latency 

Re: 3.8.2-3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

[Arkadiusz Miskiewicz]

On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
 Hello.
 
 After upgrading from 3.8.2 to 3.8.3 I'm getting regression :

More people hits this:
https://bugzilla.redhat.com/show_bug.cgi?id=922304
https://bugs.archlinux.org/task/34327
(seems always GM45 gpu in these reports)

archlinux people also noticed that xrandr reports VGA1 as connected (while in 
reality nothing is connected to VGA1)

[arekm@t400 ~]$ more xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 32767 x 32767
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm 
x 190mm
   1440x900   60.0*+   50.0  
   1024x768   60.0  
   800x60060.3 56.2  
   640x48059.9  
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1024x768   60.0* 
   800x60060.3 56.2  
   848x48060.0  
   640x48059.9  
DP1 disconnected (normal left inverted right x axis y axis)

[arekm@t400 ~]$ xrandr --output VGA --mode 1440x900
warning: output VGA not found; ignoring


Normally this looks like:
[arekm@t400 ~]$ more xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 32767 x 32767  
 
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm 
x 190mm
   1440x900   60.0*+   50.0 
 
   1024x768   60.0  
 
   800x60060.3 56.2  
   640x48059.9  
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)

 
 diff:
   [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
   [drm] Driver supports precise vblank timestamp query.
   vgaarb: device changed decodes:
 PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem + [drm]
 GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
 fbcon: inteldrmfb (fb0) is primary device
 - Console: switching to colour frame buffer device 180x56
 + Console: switching to colour frame buffer device 128x48
   i915 :00:02.0: fb0: inteldrmfb frame buffer device
   i915 :00:02.0: registered panic notifier
   acpi device:01: registered as cooling_device0
 
 console becomes weird, ends up in 2/3 of screen, X when starts gets tiny
 fonts etc.
 
 Machine is Thinkpad T400 with gm45 GPU
 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series
 Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00
 [VGA controller]) Subsystem: Lenovo Device [17aa:2112]
 
 Reverting bisected commit from 3.8.3 fixes the problem
 
 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
 commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Sat Dec 1 21:03:22 2012 +0100
 
 drm/i915: reorder setup sequence to have irqs for output setup
 
 commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.
 
 Otherwise the newshiny irq-driven gmbus and dp aux code won't work
 that well. Noticed since the dp aux code doesn't have an automatic
 fallback with a timeout (since the hw provides for that already).
 
 v2: Simple move drm_irq_install before intel_modeset_gem_init, as
 suggested by Ben Widawsky.
 
 v3: Now that interrupts are enabled before all connectors are fully
 set up, we might fall over serving a HPD interrupt while things are
 still being set up. Instead of jumping through massive hoops and
 complicating the code with a separate hpd irq enable step, simply
 block out the hotplug work item from doing anything until things are
 in place.
 
 v4: Actually, we can enable hotplug processing only after the fbdev is
 fully set up, since we call down into the fbdev from the hotplug work
 functions. So stick the hpd enabling right next to the poll helper
 initialization.
 
 v5: We need to enable irqs before intel_modeset_init, since that
 function sets up the outputs.
 
 v6: Fixup cleanup sequence, too.
 
 Reviewed-by: Imre Deak imre.d...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
 
 :04 04 26e83b14e8d49da8c451dc2c837646a337a79085
 :fa2cbfcf159808ce188675115888242245e4e69d M  drivers
 
 relevant dmesg:
 
  [drm] Initialized drm 1.1.0 20060810
  [drm] radeon defaulting to userspace modesetting.
  i915 :00:02.0: setting latency timer to 64
  i915 :00:02.0: irq 47 for MSI/MSI-X
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] Driver supports precise vblank timestamp query.
  [drm] GMBUS [i915

3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

[Arkadiusz Miskiewicz]

Hello.

After upgrading from 3.8.2 to 3.8.3 I'm getting regression :

diff:
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] Driver supports precise vblank timestamp query.
  vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
+ [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
  fbcon: inteldrmfb (fb0) is primary device
- Console: switching to colour frame buffer device 180x56
+ Console: switching to colour frame buffer device 128x48
  i915 :00:02.0: fb0: inteldrmfb frame buffer device
  i915 :00:02.0: registered panic notifier
  acpi device:01: registered as cooling_device0

console becomes weird, ends up in 2/3 of screen, X when starts gets tiny fonts 
etc.

Machine is Thinkpad T400 with gm45 GPU
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:2112]

Reverting bisected commit from 3.8.3 fixes the problem

2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
Author: Daniel Vetter 
Date:   Sat Dec 1 21:03:22 2012 +0100

drm/i915: reorder setup sequence to have irqs for output setup

commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.

Otherwise the new irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).

v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.

v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.

v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.

v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.

v6: Fixup cleanup sequence, too.

Reviewed-by: Imre Deak 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

:04 04 26e83b14e8d49da8c451dc2c837646a337a79085 
fa2cbfcf159808ce188675115888242245e4e69d M  drivers


relevant dmesg:

 [drm] Initialized drm 1.1.0 20060810
 [drm] radeon defaulting to userspace modesetting.
 i915 :00:02.0: setting latency timer to 64
 i915 :00:02.0: irq 47 for MSI/MSI-X
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
 fbcon: inteldrmfb (fb0) is primary device
 i915 :00:02.0: fb0: inteldrmfb frame buffer device
 i915 :00:02.0: registered panic notifier
 [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.8.2-3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

[Arkadiusz Miskiewicz]

Hello.

After upgrading from 3.8.2 to 3.8.3 I'm getting regression :

diff:
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] Driver supports precise vblank timestamp query.
  vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
+ [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
  fbcon: inteldrmfb (fb0) is primary device
- Console: switching to colour frame buffer device 180x56
+ Console: switching to colour frame buffer device 128x48
  i915 :00:02.0: fb0: inteldrmfb frame buffer device
  i915 :00:02.0: registered panic notifier
  acpi device:01: registered as cooling_device0

console becomes weird, ends up in 2/3 of screen, X when starts gets tiny fonts 
etc.

Machine is Thinkpad T400 with gm45 GPU
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:2112]

Reverting bisected commit from 3.8.3 fixes the problem

2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Sat Dec 1 21:03:22 2012 +0100

drm/i915: reorder setup sequence to have irqs for output setup

commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.

Otherwise the newshiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).

v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.

v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.

v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.

v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.

v6: Fixup cleanup sequence, too.

Reviewed-by: Imre Deak imre.d...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

:04 04 26e83b14e8d49da8c451dc2c837646a337a79085 
fa2cbfcf159808ce188675115888242245e4e69d M  drivers


relevant dmesg:

 [drm] Initialized drm 1.1.0 20060810
 [drm] radeon defaulting to userspace modesetting.
 i915 :00:02.0: setting latency timer to 64
 i915 :00:02.0: irq 47 for MSI/MSI-X
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
 fbcon: inteldrmfb (fb0) is primary device
 i915 :00:02.0: fb0: inteldrmfb frame buffer device
 i915 :00:02.0: registered panic notifier
 [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Sunday 20 of January 2013, Arkadiusz Miskiewicz wrote:
> On Sunday 20 of January 2013, Woody Suwalski wrote:
> > Arkadiusz Miskiewicz wrote:
> > > On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
> > >> On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
> > >>> On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
> > >>>> Hi.
> > >>>> 
> > >>>> Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
> > >>>> FT232RL, one after disconnecting another.
> > >>>> 
> > >>>> After few cycles of reconnecting and using socat (below) I'm getting
> > >>>> problems accessing ttyUSB0:
> > >>>> ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> > >>>> TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
> > >>>> 
> > >>>> Unloading and reloading (by udev) modules ftdio_sio, cp210x,
> > >>>> usbserial doesn't help. I have to reboot to get ttyUSB0 working
> > >>>> (regardless of which driver, ftdio_sio or cp210x is handling
> > >>>> ttyUSB0 - both stop working).
> > >>>> 
> > >>>> Any clues?
> > >>> 
> > >>> The kernel log shows the device getting removed a bunch and then
> > >>> coming back, which implies electrical issues (flaky connection, low
> > >>> power, etc.)  Are you really removing it and plugging it back in? 
> > >>> Or is it doing it all by itself?
> > >> 
> > >> I was doing plug in CP2102, remove it, plug in FT232RL after few
> > >> seconds, remove it, plug in CP... (and various variations, several
> > >> times) and testing with socat before removing devices. After some
> > >> iteration the problem appears and only reboot helps.
> > > 
> > > The issue is really weird. Machine is Thinkpad T400 2764CTO (latest
> > > bios). When the problem happened on 3.7.3 today I rebooted into 3.8rc4
> > > and ... freshly after reboot and plugging in PL2303 adapter the problem
> > > was already there. Didn't have to do unplug/plug cycle to make it
> > > happen.
> > > 
> > > Looks like sometimes reboot cures the problem, sometimes it doesn't.
> > > Now powered off laptop and powered it on - problem gone.
> > > 
> > > Connected PL2303, ran socat, disconnected PL2303 (while socat was
> > > running) -> problem happened again. Looks like it doesn't depend on
> > > adapter chip type.
> > > 
> > > So to reproduce here:
> > > - boot fresh 3.8rc4
> > > - plug in some adapter (PL2303 for example)
> > > - run "socat -ddd -s -u
> > > /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock -
> > > 
> > > | logger" - it should run fine, without any error
> > > 
> > > - disconnect adapter; socat should exit with error "W cannot restore
> > > terminal settings on fd 3: Input/output error"
> > > - plug in adapter again
> > > - run socat again -> this time error "E tcgetattr(3, 0x7fff21411780):
> > > Inappropriate ioctl for device" immediately always; regardless which
> > > adapter is used and if kernel module drivers for these adapters were
> > > reloaded
> > > 
> > > dmesg:
> > > http://pastebin.com/r1Q5mmgt
> > > 
> > > config:
> > > http://pastebin.com/8dpFFzuU
> > > 
> > > lspci:
> > > http://pastebin.com/TBtUg1tW
> > > 
> > > lsusb:
> > > http://pastebin.com/SueVw9CD
> > > 
> > > [   53.776047] usb 4-1: new full-speed USB device number 2 using
> > > uhci_hcd [   53.938053] usb 4-1: New USB device found, idVendor=067b,
> > > idProduct=2303 [   53.938060] usb 4-1: New USB device strings: Mfr=1,
> > > Product=2, SerialNumber=0
> > > [   53.938065] usb 4-1: Product: USB-Serial Controller
> > > [   53.938068] usb 4-1: Manufacturer: Prolific Technology Inc.
> > > [   53.949924] usbcore: registered new interface driver usbserial
> > > [   53.950364] usbcore: registered new interface driver
> > > usbserial_generic [   53.951147] usbserial: USB Serial support
> > > registered for generic [   53.954268] usbcore: registered new
> > > interface driver pl2303 [   53.955009] usbserial: USB Serial support
> > > registered for pl2303 [   53.955039] pl2303 4-1:1.0: pl2303 converter
> > > detect

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Sunday 20 of January 2013, Woody Suwalski wrote:
> Arkadiusz Miskiewicz wrote:
> > On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
> >> On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
> >>> On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
> >>>> Hi.
> >>>> 
> >>>> Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
> >>>> FT232RL, one after disconnecting another.
> >>>> 
> >>>> After few cycles of reconnecting and using socat (below) I'm getting
> >>>> problems accessing ttyUSB0:
> >>>> ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> >>>> TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
> >>>> 
> >>>> Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial
> >>>> doesn't help. I have to reboot to get ttyUSB0 working (regardless of
> >>>> which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop
> >>>> working).
> >>>> 
> >>>> Any clues?
> >>> 
> >>> The kernel log shows the device getting removed a bunch and then coming
> >>> back, which implies electrical issues (flaky connection, low power,
> >>> etc.)  Are you really removing it and plugging it back in?  Or is it
> >>> doing it all by itself?
> >> 
> >> I was doing plug in CP2102, remove it, plug in FT232RL after few
> >> seconds, remove it, plug in CP... (and various variations, several
> >> times) and testing with socat before removing devices. After some
> >> iteration the problem appears and only reboot helps.
> > 
> > The issue is really weird. Machine is Thinkpad T400 2764CTO (latest
> > bios). When the problem happened on 3.7.3 today I rebooted into 3.8rc4
> > and ... freshly after reboot and plugging in PL2303 adapter the problem
> > was already there. Didn't have to do unplug/plug cycle to make it
> > happen.
> > 
> > Looks like sometimes reboot cures the problem, sometimes it doesn't. Now
> > powered off laptop and powered it on - problem gone.
> > 
> > Connected PL2303, ran socat, disconnected PL2303 (while socat was
> > running) -> problem happened again. Looks like it doesn't depend on
> > adapter chip type.
> > 
> > So to reproduce here:
> > - boot fresh 3.8rc4
> > - plug in some adapter (PL2303 for example)
> > - run "socat -ddd -s -u
> > /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock -
> > 
> > | logger" - it should run fine, without any error
> > 
> > - disconnect adapter; socat should exit with error "W cannot restore
> > terminal settings on fd 3: Input/output error"
> > - plug in adapter again
> > - run socat again -> this time error "E tcgetattr(3, 0x7fff21411780):
> > Inappropriate ioctl for device" immediately always; regardless which
> > adapter is used and if kernel module drivers for these adapters were
> > reloaded
> > 
> > dmesg:
> > http://pastebin.com/r1Q5mmgt
> > 
> > config:
> > http://pastebin.com/8dpFFzuU
> > 
> > lspci:
> > http://pastebin.com/TBtUg1tW
> > 
> > lsusb:
> > http://pastebin.com/SueVw9CD
> > 
> > [   53.776047] usb 4-1: new full-speed USB device number 2 using uhci_hcd
> > [   53.938053] usb 4-1: New USB device found, idVendor=067b,
> > idProduct=2303 [   53.938060] usb 4-1: New USB device strings: Mfr=1,
> > Product=2, SerialNumber=0
> > [   53.938065] usb 4-1: Product: USB-Serial Controller
> > [   53.938068] usb 4-1: Manufacturer: Prolific Technology Inc.
> > [   53.949924] usbcore: registered new interface driver usbserial
> > [   53.950364] usbcore: registered new interface driver usbserial_generic
> > [   53.951147] usbserial: USB Serial support registered for generic
> > [   53.954268] usbcore: registered new interface driver pl2303
> > [   53.955009] usbserial: USB Serial support registered for pl2303
> > [   53.955039] pl2303 4-1:1.0: pl2303 converter detected
> > [   53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0
> > [   64.492122] usb 4-1: USB disconnect, device number 2
> > [   64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from
> > ttyUSB0 [   64.502343] pl2303 4-1:1.0: device disconnected
> > [   66.494930] usb 4-1: new full-speed USB device number 3 using uhci_hcd
> > [   66.654247] usb 4-1: New USB device found, idVendor=067b,
> > idProduct=2303 [   66.654261] usb 4-1

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Sunday 20 of January 2013, Woody Suwalski wrote:
 Arkadiusz Miskiewicz wrote:
  On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
  On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
  On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
  Hi.
  
  Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
  FT232RL, one after disconnecting another.
  
  After few cycles of reconnecting and using socat (below) I'm getting
  problems accessing ttyUSB0:
  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
  TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
  
  Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial
  doesn't help. I have to reboot to get ttyUSB0 working (regardless of
  which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop
  working).
  
  Any clues?
  
  The kernel log shows the device getting removed a bunch and then coming
  back, which implies electrical issues (flaky connection, low power,
  etc.)  Are you really removing it and plugging it back in?  Or is it
  doing it all by itself?
  
  I was doing plug in CP2102, remove it, plug in FT232RL after few
  seconds, remove it, plug in CP... (and various variations, several
  times) and testing with socat before removing devices. After some
  iteration the problem appears and only reboot helps.
  
  The issue is really weird. Machine is Thinkpad T400 2764CTO (latest
  bios). When the problem happened on 3.7.3 today I rebooted into 3.8rc4
  and ... freshly after reboot and plugging in PL2303 adapter the problem
  was already there. Didn't have to do unplug/plug cycle to make it
  happen.
  
  Looks like sometimes reboot cures the problem, sometimes it doesn't. Now
  powered off laptop and powered it on - problem gone.
  
  Connected PL2303, ran socat, disconnected PL2303 (while socat was
  running) - problem happened again. Looks like it doesn't depend on
  adapter chip type.
  
  So to reproduce here:
  - boot fresh 3.8rc4
  - plug in some adapter (PL2303 for example)
  - run socat -ddd -s -u
  /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock -
  
  | logger - it should run fine, without any error
  
  - disconnect adapter; socat should exit with error W cannot restore
  terminal settings on fd 3: Input/output error
  - plug in adapter again
  - run socat again - this time error E tcgetattr(3, 0x7fff21411780):
  Inappropriate ioctl for device immediately always; regardless which
  adapter is used and if kernel module drivers for these adapters were
  reloaded
  
  dmesg:
  http://pastebin.com/r1Q5mmgt
  
  config:
  http://pastebin.com/8dpFFzuU
  
  lspci:
  http://pastebin.com/TBtUg1tW
  
  lsusb:
  http://pastebin.com/SueVw9CD
  
  [   53.776047] usb 4-1: new full-speed USB device number 2 using uhci_hcd
  [   53.938053] usb 4-1: New USB device found, idVendor=067b,
  idProduct=2303 [   53.938060] usb 4-1: New USB device strings: Mfr=1,
  Product=2, SerialNumber=0
  [   53.938065] usb 4-1: Product: USB-Serial Controller
  [   53.938068] usb 4-1: Manufacturer: Prolific Technology Inc.
  [   53.949924] usbcore: registered new interface driver usbserial
  [   53.950364] usbcore: registered new interface driver usbserial_generic
  [   53.951147] usbserial: USB Serial support registered for generic
  [   53.954268] usbcore: registered new interface driver pl2303
  [   53.955009] usbserial: USB Serial support registered for pl2303
  [   53.955039] pl2303 4-1:1.0: pl2303 converter detected
  [   53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0
  [   64.492122] usb 4-1: USB disconnect, device number 2
  [   64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from
  ttyUSB0 [   64.502343] pl2303 4-1:1.0: device disconnected
  [   66.494930] usb 4-1: new full-speed USB device number 3 using uhci_hcd
  [   66.654247] usb 4-1: New USB device found, idVendor=067b,
  idProduct=2303 [   66.654261] usb 4-1: New USB device strings: Mfr=1,
  Product=2, SerialNumber=0
  [   66.654269] usb 4-1: Product: USB-Serial Controller
  [   66.654276] usb 4-1: Manufacturer: Prolific Technology Inc.
  [   66.659661] pl2303 4-1:1.0: pl2303 converter detected
  [   66.671587] usb 4-1: pl2303 converter now attached to ttyUSB0
  
  5722  munmap(0x7f1bfc0d7000, 4096)  = 0
  5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3,
  0x7fffeff64020): Inappropriate ioctl for device\n, 95) = 95
  5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
  TCGETS, 0x7fffeff63e50) = -1 ENOTTY (Inappropriate ioctl for device)
  5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3,
  0x7fffeff63f90): Inappropriate ioctl for device\n, 95) = 95
  5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
  TCGETS, 0x7fffeff63ec0) = -1 ENOTTY (Inappropriate ioctl for device)
  5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3,
  0x7fffeff64160): Inappropriate ioctl for device\n, 95) = 95
  5722

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Sunday 20 of January 2013, Arkadiusz Miskiewicz wrote:
 On Sunday 20 of January 2013, Woody Suwalski wrote:
  Arkadiusz Miskiewicz wrote:
   On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
   On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
   On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
   Hi.
   
   Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
   FT232RL, one after disconnecting another.
   
   After few cycles of reconnecting and using socat (below) I'm getting
   problems accessing ttyUSB0:
   ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
   TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
   
   Unloading and reloading (by udev) modules ftdio_sio, cp210x,
   usbserial doesn't help. I have to reboot to get ttyUSB0 working
   (regardless of which driver, ftdio_sio or cp210x is handling
   ttyUSB0 - both stop working).
   
   Any clues?
   
   The kernel log shows the device getting removed a bunch and then
   coming back, which implies electrical issues (flaky connection, low
   power, etc.)  Are you really removing it and plugging it back in? 
   Or is it doing it all by itself?
   
   I was doing plug in CP2102, remove it, plug in FT232RL after few
   seconds, remove it, plug in CP... (and various variations, several
   times) and testing with socat before removing devices. After some
   iteration the problem appears and only reboot helps.
   
   The issue is really weird. Machine is Thinkpad T400 2764CTO (latest
   bios). When the problem happened on 3.7.3 today I rebooted into 3.8rc4
   and ... freshly after reboot and plugging in PL2303 adapter the problem
   was already there. Didn't have to do unplug/plug cycle to make it
   happen.
   
   Looks like sometimes reboot cures the problem, sometimes it doesn't.
   Now powered off laptop and powered it on - problem gone.
   
   Connected PL2303, ran socat, disconnected PL2303 (while socat was
   running) - problem happened again. Looks like it doesn't depend on
   adapter chip type.
   
   So to reproduce here:
   - boot fresh 3.8rc4
   - plug in some adapter (PL2303 for example)
   - run socat -ddd -s -u
   /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock -
   
   | logger - it should run fine, without any error
   
   - disconnect adapter; socat should exit with error W cannot restore
   terminal settings on fd 3: Input/output error
   - plug in adapter again
   - run socat again - this time error E tcgetattr(3, 0x7fff21411780):
   Inappropriate ioctl for device immediately always; regardless which
   adapter is used and if kernel module drivers for these adapters were
   reloaded
   
   dmesg:
   http://pastebin.com/r1Q5mmgt
   
   config:
   http://pastebin.com/8dpFFzuU
   
   lspci:
   http://pastebin.com/TBtUg1tW
   
   lsusb:
   http://pastebin.com/SueVw9CD
   
   [   53.776047] usb 4-1: new full-speed USB device number 2 using
   uhci_hcd [   53.938053] usb 4-1: New USB device found, idVendor=067b,
   idProduct=2303 [   53.938060] usb 4-1: New USB device strings: Mfr=1,
   Product=2, SerialNumber=0
   [   53.938065] usb 4-1: Product: USB-Serial Controller
   [   53.938068] usb 4-1: Manufacturer: Prolific Technology Inc.
   [   53.949924] usbcore: registered new interface driver usbserial
   [   53.950364] usbcore: registered new interface driver
   usbserial_generic [   53.951147] usbserial: USB Serial support
   registered for generic [   53.954268] usbcore: registered new
   interface driver pl2303 [   53.955009] usbserial: USB Serial support
   registered for pl2303 [   53.955039] pl2303 4-1:1.0: pl2303 converter
   detected
   [   53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0
   [   64.492122] usb 4-1: USB disconnect, device number 2
   [   64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from
   ttyUSB0 [   64.502343] pl2303 4-1:1.0: device disconnected
   [   66.494930] usb 4-1: new full-speed USB device number 3 using
   uhci_hcd [   66.654247] usb 4-1: New USB device found, idVendor=067b,
   idProduct=2303 [   66.654261] usb 4-1: New USB device strings: Mfr=1,
   Product=2, SerialNumber=0
   [   66.654269] usb 4-1: Product: USB-Serial Controller
   [   66.654276] usb 4-1: Manufacturer: Prolific Technology Inc.
   [   66.659661] pl2303 4-1:1.0: pl2303 converter detected
   [   66.671587] usb 4-1: pl2303 converter now attached to ttyUSB0
   
   5722  munmap(0x7f1bfc0d7000, 4096)  = 0
   5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3,
   0x7fffeff64020): Inappropriate ioctl for device\n, 95) = 95
   5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
   TCGETS, 0x7fffeff63e50) = -1 ENOTTY (Inappropriate ioctl for device)
   5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3,
   0x7fffeff63f90): Inappropriate ioctl for device\n, 95) = 95
   5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
   TCGETS, 0x7fffeff63ec0) = -1 ENOTTY

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
> On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
> > On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
> > > Hi.
> > > 
> > > Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
> > > FT232RL, one after disconnecting another.
> > > 
> > > After few cycles of reconnecting and using socat (below) I'm getting
> > > problems accessing ttyUSB0:
> > > ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> > > TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
> > > 
> > > Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial
> > > doesn't help. I have to reboot to get ttyUSB0 working (regardless of
> > > which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop
> > > working).
> > > 
> > > Any clues?
> > 
> > The kernel log shows the device getting removed a bunch and then coming
> > back, which implies electrical issues (flaky connection, low power,
> > etc.)  Are you really removing it and plugging it back in?  Or is it
> > doing it all by itself?
> 
> I was doing plug in CP2102, remove it, plug in FT232RL after few seconds,
> remove it, plug in CP... (and various variations, several times) and
> testing with socat before removing devices. After some iteration the
> problem appears and only reboot helps.

The issue is really weird. Machine is Thinkpad T400 2764CTO (latest bios). 
When the problem happened on 3.7.3 today I rebooted into 3.8rc4 and ... 
freshly after reboot and plugging in PL2303 adapter the problem was already 
there. Didn't have to do unplug/plug cycle to make it happen.

Looks like sometimes reboot cures the problem, sometimes it doesn't. Now 
powered off laptop and powered it on - problem gone.

Connected PL2303, ran socat, disconnected PL2303 (while socat was running) -> 
problem happened again. Looks like it doesn't depend on adapter chip type.

So to reproduce here:
- boot fresh 3.8rc4
- plug in some adapter (PL2303 for example)
- run "socat -ddd -s -u /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock - 
| logger" - it should run fine, without any error
- disconnect adapter; socat should exit with error "W cannot restore terminal 
settings on fd 3: Input/output error"
- plug in adapter again
- run socat again -> this time error "E tcgetattr(3, 0x7fff21411780): 
Inappropriate ioctl for device" immediately always; regardless which adapter 
is used and if kernel module drivers for these adapters were reloaded

dmesg:
http://pastebin.com/r1Q5mmgt

config:
http://pastebin.com/8dpFFzuU

lspci:
http://pastebin.com/TBtUg1tW

lsusb:
http://pastebin.com/SueVw9CD

[   53.776047] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[   53.938053] usb 4-1: New USB device found, idVendor=067b, idProduct=2303
[   53.938060] usb 4-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   53.938065] usb 4-1: Product: USB-Serial Controller
[   53.938068] usb 4-1: Manufacturer: Prolific Technology Inc.
[   53.949924] usbcore: registered new interface driver usbserial
[   53.950364] usbcore: registered new interface driver usbserial_generic
[   53.951147] usbserial: USB Serial support registered for generic
[   53.954268] usbcore: registered new interface driver pl2303
[   53.955009] usbserial: USB Serial support registered for pl2303
[   53.955039] pl2303 4-1:1.0: pl2303 converter detected
[   53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0
[   64.492122] usb 4-1: USB disconnect, device number 2
[   64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[   64.502343] pl2303 4-1:1.0: device disconnected
[   66.494930] usb 4-1: new full-speed USB device number 3 using uhci_hcd
[   66.654247] usb 4-1: New USB device found, idVendor=067b, idProduct=2303
[   66.654261] usb 4-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   66.654269] usb 4-1: Product: USB-Serial Controller
[   66.654276] usb 4-1: Manufacturer: Prolific Technology Inc.
[   66.659661] pl2303 4-1:1.0: pl2303 converter detected
[   66.671587] usb 4-1: pl2303 converter now attached to ttyUSB0

5722  munmap(0x7f1bfc0d7000, 4096)  = 0
5722  write(2, "2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 
0x7fffeff64020): Inappropriate ioctl for device\n", 95) = 95
5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x7fffeff63e50) = -1 ENOTTY (Inappropriate ioctl for device)
5722  write(2, "2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 
0x7fffeff63f90): Inappropriate ioctl for device\n", 95) = 95
5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x7fffeff63ec0) = -1 ENOTTY (Inappropriate ioctl for device)
5722  write(2, 

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
> On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
> > Hi.
> > 
> > Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
> > FT232RL, one after disconnecting another.
> > 
> > After few cycles of reconnecting and using socat (below) I'm getting
> > problems accessing ttyUSB0:
> > ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
> > 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
> > 
> > Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial
> > doesn't help. I have to reboot to get ttyUSB0 working (regardless of
> > which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop
> > working).
> > 
> > Any clues?
> 
> The kernel log shows the device getting removed a bunch and then coming
> back, which implies electrical issues (flaky connection, low power,
> etc.)  Are you really removing it and plugging it back in?  Or is it
> doing it all by itself?

I was doing plug in CP2102, remove it, plug in FT232RL after few seconds, 
remove it, plug in CP... (and various variations, several times) and testing 
with socat before removing devices. After some iteration the problem appears 
and only reboot helps.




Reproducible. suspend to ram/resume cycle didn't change anything, device still 
has a problem, even after reconnection of device.

> 
> thanks,
> 
> greg k-h


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

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
 On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
  Hi.
  
  Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
  FT232RL, one after disconnecting another.
  
  After few cycles of reconnecting and using socat (below) I'm getting
  problems accessing ttyUSB0:
  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
  0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
  
  Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial
  doesn't help. I have to reboot to get ttyUSB0 working (regardless of
  which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop
  working).
  
  Any clues?
 
 The kernel log shows the device getting removed a bunch and then coming
 back, which implies electrical issues (flaky connection, low power,
 etc.)  Are you really removing it and plugging it back in?  Or is it
 doing it all by itself?

I was doing plug in CP2102, remove it, plug in FT232RL after few seconds, 
remove it, plug in CP... (and various variations, several times) and testing 
with socat before removing devices. After some iteration the problem appears 
and only reboot helps.




Reproducible. suspend to ram/resume cycle didn't change anything, device still 
has a problem, even after reconnection of device.

 
 thanks,
 
 greg k-h


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)

[Arkadiusz Miskiewicz]

On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
 On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
  On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
   Hi.
   
   Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and
   FT232RL, one after disconnecting another.
   
   After few cycles of reconnecting and using socat (below) I'm getting
   problems accessing ttyUSB0:
   ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
   TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device)
   
   Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial
   doesn't help. I have to reboot to get ttyUSB0 working (regardless of
   which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop
   working).
   
   Any clues?
  
  The kernel log shows the device getting removed a bunch and then coming
  back, which implies electrical issues (flaky connection, low power,
  etc.)  Are you really removing it and plugging it back in?  Or is it
  doing it all by itself?
 
 I was doing plug in CP2102, remove it, plug in FT232RL after few seconds,
 remove it, plug in CP... (and various variations, several times) and
 testing with socat before removing devices. After some iteration the
 problem appears and only reboot helps.

The issue is really weird. Machine is Thinkpad T400 2764CTO (latest bios). 
When the problem happened on 3.7.3 today I rebooted into 3.8rc4 and ... 
freshly after reboot and plugging in PL2303 adapter the problem was already 
there. Didn't have to do unplug/plug cycle to make it happen.

Looks like sometimes reboot cures the problem, sometimes it doesn't. Now 
powered off laptop and powered it on - problem gone.

Connected PL2303, ran socat, disconnected PL2303 (while socat was running) - 
problem happened again. Looks like it doesn't depend on adapter chip type.

So to reproduce here:
- boot fresh 3.8rc4
- plug in some adapter (PL2303 for example)
- run socat -ddd -s -u /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock - 
| logger - it should run fine, without any error
- disconnect adapter; socat should exit with error W cannot restore terminal 
settings on fd 3: Input/output error
- plug in adapter again
- run socat again - this time error E tcgetattr(3, 0x7fff21411780): 
Inappropriate ioctl for device immediately always; regardless which adapter 
is used and if kernel module drivers for these adapters were reloaded

dmesg:
http://pastebin.com/r1Q5mmgt

config:
http://pastebin.com/8dpFFzuU

lspci:
http://pastebin.com/TBtUg1tW

lsusb:
http://pastebin.com/SueVw9CD

[   53.776047] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[   53.938053] usb 4-1: New USB device found, idVendor=067b, idProduct=2303
[   53.938060] usb 4-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   53.938065] usb 4-1: Product: USB-Serial Controller
[   53.938068] usb 4-1: Manufacturer: Prolific Technology Inc.
[   53.949924] usbcore: registered new interface driver usbserial
[   53.950364] usbcore: registered new interface driver usbserial_generic
[   53.951147] usbserial: USB Serial support registered for generic
[   53.954268] usbcore: registered new interface driver pl2303
[   53.955009] usbserial: USB Serial support registered for pl2303
[   53.955039] pl2303 4-1:1.0: pl2303 converter detected
[   53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0
[   64.492122] usb 4-1: USB disconnect, device number 2
[   64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[   64.502343] pl2303 4-1:1.0: device disconnected
[   66.494930] usb 4-1: new full-speed USB device number 3 using uhci_hcd
[   66.654247] usb 4-1: New USB device found, idVendor=067b, idProduct=2303
[   66.654261] usb 4-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[   66.654269] usb 4-1: Product: USB-Serial Controller
[   66.654276] usb 4-1: Manufacturer: Prolific Technology Inc.
[   66.659661] pl2303 4-1:1.0: pl2303 converter detected
[   66.671587] usb 4-1: pl2303 converter now attached to ttyUSB0

5722  munmap(0x7f1bfc0d7000, 4096)  = 0
5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 
0x7fffeff64020): Inappropriate ioctl for device\n, 95) = 95
5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x7fffeff63e50) = -1 ENOTTY (Inappropriate ioctl for device)
5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 
0x7fffeff63f90): Inappropriate ioctl for device\n, 95) = 95
5722  ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x7fffeff63ec0) = -1 ENOTTY (Inappropriate ioctl for device)
5722  write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 
0x7fffeff64160): Inappropriate ioctl for device\n, 95) = 95
5722  fcntl(3, F_SETFD, FD_CLOEXEC) = 0
5722  ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0x7fffeff64330) = -1 ENOTTY (Inappropriate ioctl for device)
5722  select(4, [3], [1], [], NULL

Re: [3.5.y.z extended stable] Linux 3.5.7.1

[Arkadiusz Miskiewicz]

On Thursday 29 of November 2012, Herton Ronaldo Krzesinski wrote:
> I am announcing the release of the 3.5.7.1 tree of stable patches.
> 
> This tree picks up the latest 3.5 stable release upstream, and add patches
> on top that were later marked for stable but can't be added to 3.5, as
> it is not anymore an stable series maintained upstream.

Could this tree become real stable release for 3.5 with typical scheme 
(patches, tarballs, git tree on kernel.org) ?

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

Re: [3.5.y.z extended stable] Linux 3.5.7.1

[Arkadiusz Miskiewicz]

On Thursday 29 of November 2012, Herton Ronaldo Krzesinski wrote:
 I am announcing the release of the 3.5.7.1 tree of stable patches.
 
 This tree picks up the latest 3.5 stable release upstream, and add patches
 on top that were later marked for stable but can't be added to 3.5, as
 it is not anymore an stable series maintained upstream.

Could this tree become real stable release for 3.5 with typical scheme 
(patches, tarballs, git tree on kernel.org) ?

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/27] 2.6.22-stable review

[Arkadiusz Miskiewicz]

On Saturday 02 of February 2008, you wrote:
> This is the start of the stable review cycle for the 2.6.22.17 release.
> There are 27 patches in this series, all will be posted as a response to
> this one.  If anyone has any issues with these being applied, please let
> us know.  If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.

btw. does this program hang for anyone on 2.6.22 (process in D state) ?

#include 
#include 
 
int main( void )
{
cpu_set_t cpu;
int cpus = 0;
int ret;
ret = sched_getaffinity(getpid(), sizeof(cpu), );
printf( "cpus = %d, ret = %d\n", cpu, ret );
sched_setaffinity(getpid(), sizeof(cpu), );
printf( "ret = %d\n" );
return ret;
}


-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/27] 2.6.22-stable review

[Arkadiusz Miskiewicz]

On Saturday 02 of February 2008, you wrote:
 This is the start of the stable review cycle for the 2.6.22.17 release.
 There are 27 patches in this series, all will be posted as a response to
 this one.  If anyone has any issues with these being applied, please let
 us know.  If anyone is a maintainer of the proper subsystem, and wants
 to add a Signed-off-by: line to the patch, please respond with it.

btw. does this program hang for anyone on 2.6.22 (process in D state) ?

#include stdio.h
#include sched.h
 
int main( void )
{
cpu_set_t cpu;
int cpus = 0;
int ret;
ret = sched_getaffinity(getpid(), sizeof(cpu), cpu);
printf( cpus = %d, ret = %d\n, cpu, ret );
sched_setaffinity(getpid(), sizeof(cpu), cpu);
printf( ret = %d\n );
return ret;
}


-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: git guidance

[Arkadiusz Miskiewicz]

On Tuesday 27 of November 2007, Tilman Schmidt wrote:
> So I've watched Linus' Google Tech Talk about git and let him convince
> me that I've been stupid to use CVS, that Subversion is even worse,
> and the only sensible approach is to use git. Went ahead and tried to
> convert my driver development to git.

You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's better 
8-)

> TIA

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: git guidance

[Arkadiusz Miskiewicz]

On Tuesday 27 of November 2007, Tilman Schmidt wrote:
 So I've watched Linus' Google Tech Talk about git and let him convince
 me that I've been stupid to use CVS, that Subversion is even worse,
 and the only sensible approach is to use git. Went ahead and tried to
 convert my driver development to git.

You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's better 
8-)

 TIA

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3/3] 2.6.23-rc6: known regressions v2

[Arkadiusz Miskiewicz]

On Monday 17 of September 2007, Thomas Gleixner wrote:
> On Mon, 2007-09-17 at 21:44 +0200, Arkadiusz Miskiewicz wrote:
> > On Saturday 15 of September 2007, Rafael J. Wysocki wrote:
> > > On Saturday, 15 September 2007 04:29, Michal Piotrowski wrote:
> > > > Subject : resume from ram much slower
> > > > References  : http://lkml.org/lkml/2007/8/10/275
> > > > Last known good : 2.6.23-rc1 ?
> > > > Submitter   : Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
> > > > Caused-By   : ?
> > > > Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > Status  : problem is being debugged
> > >
> > > Unresolved, bisection might be helpful.
> >
> > Took 16 hours of bisecting and playing with stuff.
> >
> > It looks like the problematic patch is
> > 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6. bisection was hard and I'm 95%
> > sure that this is the problematic patch. I'm currently using 2.6.23-rc6
> > with this reverted and so far resume works as it should.
> >
> >
> > commit 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6
> > Author: Thomas Gleixner <[EMAIL PROTECTED]>
> > Date:   Sat Jul 21 04:37:34 2007 -0700
> >
> > clockevents: fix resume logic
>
> Linus pulled a series of patches which are addressing this issue into
> his tree yesterday. Can you please retest against current git ?

Looks like the problem is fixed in current git for me. Thanks!

ps. The description about vaio not resuming without key pressing matches what 
I was seeing here on thinkpad z60m, too.

>   tglx



-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3/3] 2.6.23-rc6: known regressions v2

[Arkadiusz Miskiewicz]

On Saturday 15 of September 2007, Rafael J. Wysocki wrote:
> On Saturday, 15 September 2007 04:29, Michal Piotrowski wrote:

> > Subject : resume from ram much slower
> > References  : http://lkml.org/lkml/2007/8/10/275
> > Last known good : 2.6.23-rc1 ?
> > Submitter   : Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
> > Caused-By   : ?
> > Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
> > Status  : problem is being debugged
>
> Unresolved, bisection might be helpful.

Took 16 hours of bisecting and playing with stuff.

It looks like the problematic patch is 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6.
bisection was hard and I'm 95% sure that this is the problematic patch.
I'm currently using 2.6.23-rc6 with this reverted and so far resume works as it 
should.


commit 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date:   Sat Jul 21 04:37:34 2007 -0700

clockevents: fix resume logic

We need to make sure, that the clockevent devices are resumed, before
the tick is resumed. The current resume logic does not guarantee this.

Add CLOCK_EVT_MODE_RESUME and call the set mode functions of the clock
event devices before resuming the tick / oneshot functionality.

Fixup the existing users.

Thanks to Nigel Cunningham for tracking down a long standing thinko,
which affected the jinxed VAIO.

[EMAIL PROTECTED]: xen build fix]
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 4d8425d..e96a3dc 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -285,6 +285,8 @@ static void davinci_set_mode(enum clock_event_mode mode,
case CLOCK_EVT_MODE_SHUTDOWN:
t->opts = TIMER_OPTS_DISABLED;
break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
}
 }
 
diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index 010f6fa..d86d124 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -159,6 +159,7 @@ static void imx_set_mode(enum clock_event_mode mode, struct 
clock_event_device *
break;
case CLOCK_EVT_MODE_SHUTDOWN:
case CLOCK_EVT_MODE_UNUSED:
+   case CLOCK_EVT_MODE_RESUME:
/* Left event sources disabled, no more interrupts appears */
break;
}
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 8112f72..23e7fba 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -459,6 +459,8 @@ static void ixp4xx_set_mode(enum clock_event_mode mode,
default:
osrt = opts = 0;
break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
}
 
*IXP4XX_OSRT1 = osrt | opts;
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 3705d20..237651e 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -156,6 +156,7 @@ static void omap_mpu_set_mode(enum clock_event_mode mode,
break;
case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
+   case CLOCK_EVT_MODE_RESUME:
break;
}
 }
diff --git a/arch/arm/plat-omap/timer32k.c b/arch/arm/plat-omap/timer32k.c
index 2feceec..b0af014 100644
--- a/arch/arm/plat-omap/timer32k.c
+++ b/arch/arm/plat-omap/timer32k.c
@@ -156,6 +156,8 @@ static void omap_32k_timer_set_mode(enum clock_event_mode 
mode,
case CLOCK_EVT_MODE_SHUTDOWN:
omap_32k_timer_stop();
break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
}
 }
 
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 67824f3..610f44b 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -263,6 +263,9 @@ static void lapic_timer_setup(enum clock_event_mode mode,
v |= (APIC_LVT_MASKED | LOCAL_TIMER_VECTOR);
apic_write_around(APIC_LVTT, v);
break;
+   case CLOCK_EVT_MODE_RESUME:
+   /* Nothing to do here */
+   break;
}
 
local_irq_restore(flags);
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 17d7345..cfbf792 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -187,6 +187,10 @@ static void hpet_set_mode(enum clock_event_mode mode,
cfg &= ~HPET_TN_ENABLE;
hpet_writel(cfg, HPET_T0_CFG);
break;
+
+   case CLOCK_EVT_MODE_RESUME:
+   hpet_enable_int();
+   break;
}
 

Re: [3/3] 2.6.23-rc6: known regressions v2

[Arkadiusz Miskiewicz]

On Saturday 15 of September 2007, Rafael J. Wysocki wrote:
 On Saturday, 15 September 2007 04:29, Michal Piotrowski wrote:

  Subject : resume from ram much slower
  References  : http://lkml.org/lkml/2007/8/10/275
  Last known good : 2.6.23-rc1 ?
  Submitter   : Arkadiusz Miskiewicz [EMAIL PROTECTED]
  Caused-By   : ?
  Handled-By  : Rafael J. Wysocki [EMAIL PROTECTED]
  Status  : problem is being debugged

 Unresolved, bisection might be helpful.

Took 16 hours of bisecting and playing with stuff.

It looks like the problematic patch is 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6.
bisection was hard and I'm 95% sure that this is the problematic patch.
I'm currently using 2.6.23-rc6 with this reverted and so far resume works as it 
should.


commit 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6
Author: Thomas Gleixner [EMAIL PROTECTED]
Date:   Sat Jul 21 04:37:34 2007 -0700

clockevents: fix resume logic

We need to make sure, that the clockevent devices are resumed, before
the tick is resumed. The current resume logic does not guarantee this.

Add CLOCK_EVT_MODE_RESUME and call the set mode functions of the clock
event devices before resuming the tick / oneshot functionality.

Fixup the existing users.

Thanks to Nigel Cunningham for tracking down a long standing thinko,
which affected the jinxed VAIO.

[EMAIL PROTECTED]: xen build fix]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Cc: john stultz [EMAIL PROTECTED]
Cc: Rusty Russell [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 4d8425d..e96a3dc 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -285,6 +285,8 @@ static void davinci_set_mode(enum clock_event_mode mode,
case CLOCK_EVT_MODE_SHUTDOWN:
t-opts = TIMER_OPTS_DISABLED;
break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
}
 }
 
diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index 010f6fa..d86d124 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -159,6 +159,7 @@ static void imx_set_mode(enum clock_event_mode mode, struct 
clock_event_device *
break;
case CLOCK_EVT_MODE_SHUTDOWN:
case CLOCK_EVT_MODE_UNUSED:
+   case CLOCK_EVT_MODE_RESUME:
/* Left event sources disabled, no more interrupts appears */
break;
}
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 8112f72..23e7fba 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -459,6 +459,8 @@ static void ixp4xx_set_mode(enum clock_event_mode mode,
default:
osrt = opts = 0;
break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
}
 
*IXP4XX_OSRT1 = osrt | opts;
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 3705d20..237651e 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -156,6 +156,7 @@ static void omap_mpu_set_mode(enum clock_event_mode mode,
break;
case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
+   case CLOCK_EVT_MODE_RESUME:
break;
}
 }
diff --git a/arch/arm/plat-omap/timer32k.c b/arch/arm/plat-omap/timer32k.c
index 2feceec..b0af014 100644
--- a/arch/arm/plat-omap/timer32k.c
+++ b/arch/arm/plat-omap/timer32k.c
@@ -156,6 +156,8 @@ static void omap_32k_timer_set_mode(enum clock_event_mode 
mode,
case CLOCK_EVT_MODE_SHUTDOWN:
omap_32k_timer_stop();
break;
+   case CLOCK_EVT_MODE_RESUME:
+   break;
}
 }
 
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 67824f3..610f44b 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -263,6 +263,9 @@ static void lapic_timer_setup(enum clock_event_mode mode,
v |= (APIC_LVT_MASKED | LOCAL_TIMER_VECTOR);
apic_write_around(APIC_LVTT, v);
break;
+   case CLOCK_EVT_MODE_RESUME:
+   /* Nothing to do here */
+   break;
}
 
local_irq_restore(flags);
diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 17d7345..cfbf792 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -187,6 +187,10 @@ static void hpet_set_mode(enum clock_event_mode mode,
cfg = ~HPET_TN_ENABLE;
hpet_writel(cfg, HPET_T0_CFG);
break;
+
+   case CLOCK_EVT_MODE_RESUME:
+   hpet_enable_int();
+   break;
}
 }
 
@@ -217,6 +221,7 @@ static struct clocksource clocksource_hpet = {
.mask   = HPET_MASK,
.shift  = HPET_SHIFT

Re: [3/3] 2.6.23-rc6: known regressions v2

[Arkadiusz Miskiewicz]

On Monday 17 of September 2007, Thomas Gleixner wrote:
 On Mon, 2007-09-17 at 21:44 +0200, Arkadiusz Miskiewicz wrote:
  On Saturday 15 of September 2007, Rafael J. Wysocki wrote:
   On Saturday, 15 September 2007 04:29, Michal Piotrowski wrote:
Subject : resume from ram much slower
References  : http://lkml.org/lkml/2007/8/10/275
Last known good : 2.6.23-rc1 ?
Submitter   : Arkadiusz Miskiewicz [EMAIL PROTECTED]
Caused-By   : ?
Handled-By  : Rafael J. Wysocki [EMAIL PROTECTED]
Status  : problem is being debugged
  
   Unresolved, bisection might be helpful.
 
  Took 16 hours of bisecting and playing with stuff.
 
  It looks like the problematic patch is
  18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6. bisection was hard and I'm 95%
  sure that this is the problematic patch. I'm currently using 2.6.23-rc6
  with this reverted and so far resume works as it should.
 
 
  commit 18de5bc4c1f1f1fa5e14f354a7603bd6e9d4e3b6
  Author: Thomas Gleixner [EMAIL PROTECTED]
  Date:   Sat Jul 21 04:37:34 2007 -0700
 
  clockevents: fix resume logic

 Linus pulled a series of patches which are addressing this issue into
 his tree yesterday. Can you please retest against current git ?

Looks like the problem is fixed in current git for me. Thanks!

ps. The description about vaio not resuming without key pressing matches what 
I was seeing here on thinkpad z60m, too.

   tglx



-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix race with shared tag queue maps

[Arkadiusz Miskiewicz]

On Thursday 13 of September 2007, Jens Axboe wrote:
> Hi,
>
> There's a race condition in blk_queue_end_tag() for shared tag maps,
> users include stex (promise supertrak thingy) and qla2xxx.
[...]
> I'm cc'ing users that reported stex 
> problems, hopefully they can test this patch and report back.

I'm running 2.6.22 with f3da54ba140c6427fa4a32913e1bf406f41b5dda patch from 
Linus git tree (instead of Ed Lin workaround patch) and doing heavy rsync for 
last 8 hours. No oops - seems to be working fine (+stex driver).

Thanks!

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix race with shared tag queue maps

[Arkadiusz Miskiewicz]

On Thursday 13 of September 2007, Jens Axboe wrote:
 Hi,

 There's a race condition in blk_queue_end_tag() for shared tag maps,
 users include stex (promise supertrak thingy) and qla2xxx.
[...]
 I'm cc'ing users that reported stex 
 problems, hopefully they can test this patch and report back.

I'm running 2.6.22 with f3da54ba140c6427fa4a32913e1bf406f41b5dda patch from 
Linus git tree (instead of Ed Lin workaround patch) and doing heavy rsync for 
last 8 hours. No oops - seems to be working fine (+stex driver).

Thanks!

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [4/4] 2.6.23-rc4: known regressions

[Arkadiusz Miskiewicz]

On Monday 03 of September 2007, Michal Piotrowski wrote:
> Hi,
>
> On 30/08/07, Soeren Sonnenburg <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-08-29 at 17:27 +0200, Michal Piotrowski wrote:
> > > Power management
> > >
> > > Subject : something broke resume from s2ram on mbp c1d (??? :))
> > > References  : http://lkml.org/lkml/2007/8/28/67
> > > Last known good : 2.6.23-rc3
> > > Submitter   : Soeren Sonnenburg <[EMAIL PROTECTED]>
> > > Caused-By   : ?
> > > Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > Status  : unknown
> > >
> > > Subject : resume from ram much slower
> > > References  : http://lkml.org/lkml/2007/8/10/275
> > > Last known good : 2.6.23-rc1 ?
> > > Submitter   : Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
> > > Caused-By   : ?
> > > Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > Status  : problem is being debugged
> >
> > I am not sure whether the problem I am having is not the very same as
> > the one Arkadiusz is seeing. At least I've found resume from s2ram to be
> > working a couple of times. Only sometimes it took long to resume, that
> > is >30 seconds (around 5 - which I already consider long - is normal).
> >
> > anyway this this is with the closed source fglrx kernel module,
>
> Arkadiusz, are you using any of these binary crap modules?

No.

> Regards,
> Michal

ps. had no time to do bisecting

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
> On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > > > I guess I should sent these here since it looks like not scsi bug
> > > > > > anyway.
> > > > >
> > > > > It's stex, right? It seems to have some issues with multiple
> > > > > completions of commands, which craps out the block layer of course.
> > > >
> > > > Yes, stex. I'm staying with 2.6.19 in that case since it works fine
> > > > in that version.
> > > >
> > > > So scsi bug ... 8-)
> > >
> > > And you based that conclusion on what exactly?
> >
> > Isn't drivers/scsi/* handled by [EMAIL PROTECTED] (that's what I mean)
>
> Yep indeed, I thought you meant that it was a scsi bug (and not an stex
> one). You could try and copy the 2.6.19 stex driver into 2.6.20 and see
> if that works, though.

Looks like this bug is known for months :-(

Ed Lin pointed to http://lkml.org/lkml/2007/1/23/268 with possible patch (that 
unfortunately serialises access to storage devices, well...)

There is also: http://bugzilla.kernel.org/show_bug.cgi?id=7842

I'm running 2.6.22 with that patch now, did huge (few hours) rsync that 
previously caused oopses and now everything works properly.

Can we get some form of this patch into Linus tree?

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
 On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
  On Wednesday 29 of August 2007, Jens Axboe wrote:
   On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
On Wednesday 29 of August 2007, Jens Axboe wrote:
 On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
  I guess I should sent these here since it looks like not scsi bug
  anyway.

 It's stex, right? It seems to have some issues with multiple
 completions of commands, which craps out the block layer of course.
   
Yes, stex. I'm staying with 2.6.19 in that case since it works fine
in that version.
   
So scsi bug ... 8-)
  
   And you based that conclusion on what exactly?
 
  Isn't drivers/scsi/* handled by [EMAIL PROTECTED] (that's what I mean)

 Yep indeed, I thought you meant that it was a scsi bug (and not an stex
 one). You could try and copy the 2.6.19 stex driver into 2.6.20 and see
 if that works, though.

Looks like this bug is known for months :-(

Ed Lin pointed to http://lkml.org/lkml/2007/1/23/268 with possible patch (that 
unfortunately serialises access to storage devices, well...)

There is also: http://bugzilla.kernel.org/show_bug.cgi?id=7842

I'm running 2.6.22 with that patch now, did huge (few hours) rsync that 
previously caused oopses and now everything works properly.

Can we get some form of this patch into Linus tree?

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
> On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > On Wednesday 29 of August 2007, Jens Axboe wrote:
> > > On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > > > I guess I should sent these here since it looks like not scsi bug
> > > > anyway.
> > >
> > > It's stex, right? It seems to have some issues with multiple
> > > completions of commands, which craps out the block layer of course.
> >
> > Yes, stex. I'm staying with 2.6.19 in that case since it works fine in
> > that version.
> >
> > So scsi bug ... 8-)
>
> And you based that conclusion on what exactly?

Isn't drivers/scsi/* handled by [EMAIL PROTECTED] (that's what I mean)

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
> On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
> > I guess I should sent these here since it looks like not scsi bug anyway.
>
> It's stex, right? It seems to have some issues with multiple completions
> of commands, which craps out the block layer of course.

Yes, stex. I'm staying with 2.6.19 in that case since it works fine in that 
version.

So scsi bug ... 8-)
-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

I guess I should sent these here since it looks like not scsi bug anyway.

--  Forwarded Message  --

Subject: 2.6.22 oops kernel BUG at block/elevator.c:366!
Date: Wednesday 29 of August 2007
From: Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Hello,

I'm trying to get stable kernel for Promise SuperTrak 
X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed
like this (while doing rsync):

kernel BUG at block/elevator.c:366!
invalid opcode:  [1] SMP
CPU 1
Modules linked in: softdog sch_sfq forcedeth ext3 jbd mbcache dm_mod xfs 
scsi_wait_scan sd_mod stex scsi_mod
Pid: 1139:#0, comm: xfsbufd Not tainted 2.6.22.5-0.2 #1
RIP: 0010:[]  [] elv_rb_del+0x3a/0x40
RSP: :8100759b1c00  EFLAGS: 00010046
RAX: 81000d1f5428 RBX: 81000d1f5428 RCX: 81007c1a1a00
RDX:  RSI: 81000d1f53b0 RDI: 81007c102af0
RBP: 81000d1f53b0 R08: 81004a9dab50 R09: 
R10:  R11: 880072c0 R12: 81007c102ac0
R13: 81007c1a1a00 R14: 0004 R15: 81007c102b18
FS:  2ba2cafc9be0() GS:81007d0a5b40() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2ba2cab5a158 CR3: 3c5ce000 CR4: 06e0
Process xfsbufd (pid: 1139[#0], threadinfo 8100759b, task 
81007cac1040)
Stack:  0001 81007c102ac0 81000d1f53b0 8034abe8
 0246 81000d1f53b0 81007c1a1a00 81007c102ac0
 81007c0f2d08 0004 81007c102b18 8034ad55
Call Trace:
 [] cfq_remove_request+0x78/0x1b0
 [] cfq_dispatch_insert+0x35/0x70
 [] cfq_dispatch_requests+0x1bf/0x3a0
 [] elv_next_request+0x3f/0x150
 [] lock_timer_base+0x34/0x70
 [] :scsi_mod:scsi_request_fn+0x69/0x3d0
 [] __make_request+0xe6/0x5d0
 [] generic_make_request+0x18b/0x230
 [] submit_bio+0x5a/0xf0
 [] :xfs:_xfs_buf_ioapply+0x199/0x340
 [] :xfs:xfs_buf_iorequest+0x29/0x80
 [] :xfs:xfs_bdstrat_cb+0x3b/0x50
 [] :xfs:xfsbufd+0x92/0x140
 [] :xfs:xfsbufd+0x0/0x140
 [] kthread+0x4b/0x80
 [] child_rip+0xa/0x12
 [] kthread+0x0/0x80
 [] child_rip+0x0/0x12


Code: 0f 0b eb fe 66 90 48 83 ec 08 49 89 f8 48 89 f8 31 c9 eb 09
RIP  [] elv_rb_del+0x3a/0x40
 RSP 


I can reproduce it without bigger problem.


Here are the same oopses on 2.6.20:
http://paste.stgraber.org/3138

This is 1 x dual core athlon64 on asus m2npv mainboard, 2GB RAM.
There is hw raid on fasttrack 16350 only (no software one).

Has anyone seen this ?

Going to try without cfq.

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---

--  Forwarded Message  --

Subject: Re: 2.6.22 oops kernel BUG at block/elevator.c:366!
Date: Wednesday 29 of August 2007
From: Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

On Wednesday 29 of August 2007, Arkadiusz Miskiewicz wrote:
> Hello,
>
> I'm trying to get stable kernel for Promise SuperTrak
> X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed
> like this (while doing rsync):

With anticipatory:

berta login: [ cut here ]
kernel BUG at block/as-iosched.c:1084!
invalid opcode:  [1] SMP
CPU 1
Modules linked in: softdog sch_sfq forcedeth ext3 jbd mbcache dm_mod xfs 
scsi_wait_scan sd_mod stex scsi_mod
Pid: 32:#0, comm: kblockd/1 Not tainted 2.6.22.5-0.2 #1
RIP: 0010:[]  [] 
as_dispatch_request+0x438/0x460
RSP: 0018:81007d1fddc0  EFLAGS: 00010046
RAX:  RBX: 81007c765a00 RCX: 
RDX: 81007c765a28 RSI:  RDI: 81007c54ad08
RBP:  R08:  R09: 81006a289d80
R10:  R11: 0001 R12: 
R13: 0001 R14:  R15: 81007cf85048
FS:  2ba4421e8b00() GS:81007d0a5b40() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2ba46298f000 CR3: 50951000 CR4: 06e0
Process kblockd/1 (pid: 32[#0], threadinfo 81007d1fc000, task 
81007d1db040)
Stack:  81007c54ad08 81007cf85000 81007cf7e000 81007d1fde00
 81006a289cc0 8033f11f 0287 88000fa8
 81001646a6f8  81007cf85000 81007cf7e000
Call Trace:
 [] elv_next_request+0x3f/0x150
 [] :scsi_mod:scsi_dispatch_cmd+0x1c8/0x310
 [] :scsi_mod:scsi_request_fn+0x69/0x3d0
 [] as_work_handler+0x0/0x50
 [] as_work_handler+0x2c/0x50
 [] run_workqueue+0xcc/0x170
 [] worker_thread+0x0/0x110
 [] worker_thread+0x0/0x110
 [] worker_thread+0xa3/0x110
 [] autoremove_wake_function+0x0/0x30
 [] worker_thread+0x0/0x110
 [] worker_thread+0x0/0x110
 [] kthread+0x4b/0x80
 [] ch

2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

I guess I should sent these here since it looks like not scsi bug anyway.

--  Forwarded Message  --

Subject: 2.6.22 oops kernel BUG at block/elevator.c:366!
Date: Wednesday 29 of August 2007
From: Arkadiusz Miskiewicz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

Hello,

I'm trying to get stable kernel for Promise SuperTrak 
X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed
like this (while doing rsync):

kernel BUG at block/elevator.c:366!
invalid opcode:  [1] SMP
CPU 1
Modules linked in: softdog sch_sfq forcedeth ext3 jbd mbcache dm_mod xfs 
scsi_wait_scan sd_mod stex scsi_mod
Pid: 1139:#0, comm: xfsbufd Not tainted 2.6.22.5-0.2 #1
RIP: 0010:[8033f5da]  [8033f5da] elv_rb_del+0x3a/0x40
RSP: :8100759b1c00  EFLAGS: 00010046
RAX: 81000d1f5428 RBX: 81000d1f5428 RCX: 81007c1a1a00
RDX:  RSI: 81000d1f53b0 RDI: 81007c102af0
RBP: 81000d1f53b0 R08: 81004a9dab50 R09: 
R10:  R11: 880072c0 R12: 81007c102ac0
R13: 81007c1a1a00 R14: 0004 R15: 81007c102b18
FS:  2ba2cafc9be0() GS:81007d0a5b40() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2ba2cab5a158 CR3: 3c5ce000 CR4: 06e0
Process xfsbufd (pid: 1139[#0], threadinfo 8100759b, task 
81007cac1040)
Stack:  0001 81007c102ac0 81000d1f53b0 8034abe8
 0246 81000d1f53b0 81007c1a1a00 81007c102ac0
 81007c0f2d08 0004 81007c102b18 8034ad55
Call Trace:
 [8034abe8] cfq_remove_request+0x78/0x1b0
 [8034ad55] cfq_dispatch_insert+0x35/0x70
 [8034b61f] cfq_dispatch_requests+0x1bf/0x3a0
 [8033f11f] elv_next_request+0x3f/0x150
 [80243b04] lock_timer_base+0x34/0x70
 [88007329] :scsi_mod:scsi_request_fn+0x69/0x3d0
 [80343d46] __make_request+0xe6/0x5d0
 [8034158b] generic_make_request+0x18b/0x230
 [8034438a] submit_bio+0x5a/0xf0
 [8808d1e9] :xfs:_xfs_buf_ioapply+0x199/0x340
 [8808e099] :xfs:xfs_buf_iorequest+0x29/0x80
 [88092fbb] :xfs:xfs_bdstrat_cb+0x3b/0x50
 [8808e3c2] :xfs:xfsbufd+0x92/0x140
 [8808e330] :xfs:xfsbufd+0x0/0x140
 [8024fa3b] kthread+0x4b/0x80
 [8020b0a8] child_rip+0xa/0x12
 [8024f9f0] kthread+0x0/0x80
 [8020b09e] child_rip+0x0/0x12


Code: 0f 0b eb fe 66 90 48 83 ec 08 49 89 f8 48 89 f8 31 c9 eb 09
RIP  [8033f5da] elv_rb_del+0x3a/0x40
 RSP 8100759b1c00


I can reproduce it without bigger problem.


Here are the same oopses on 2.6.20:
http://paste.stgraber.org/3138

This is 1 x dual core athlon64 on asus m2npv mainboard, 2GB RAM.
There is hw raid on fasttrack 16350 only (no software one).

Has anyone seen this ?

Going to try without cfq.

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---

--  Forwarded Message  --

Subject: Re: 2.6.22 oops kernel BUG at block/elevator.c:366!
Date: Wednesday 29 of August 2007
From: Arkadiusz Miskiewicz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

On Wednesday 29 of August 2007, Arkadiusz Miskiewicz wrote:
 Hello,

 I'm trying to get stable kernel for Promise SuperTrak
 X16350 hardware. So far 2.6.20, 2.6.21 and 2.6.22 oopsed
 like this (while doing rsync):

With anticipatory:

berta login: [ cut here ]
kernel BUG at block/as-iosched.c:1084!
invalid opcode:  [1] SMP
CPU 1
Modules linked in: softdog sch_sfq forcedeth ext3 jbd mbcache dm_mod xfs 
scsi_wait_scan sd_mod stex scsi_mod
Pid: 32:#0, comm: kblockd/1 Not tainted 2.6.22.5-0.2 #1
RIP: 0010:[80349028]  [80349028] 
as_dispatch_request+0x438/0x460
RSP: 0018:81007d1fddc0  EFLAGS: 00010046
RAX:  RBX: 81007c765a00 RCX: 
RDX: 81007c765a28 RSI:  RDI: 81007c54ad08
RBP:  R08:  R09: 81006a289d80
R10:  R11: 0001 R12: 
R13: 0001 R14:  R15: 81007cf85048
FS:  2ba4421e8b00() GS:81007d0a5b40() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2ba46298f000 CR3: 50951000 CR4: 06e0
Process kblockd/1 (pid: 32[#0], threadinfo 81007d1fc000, task 
81007d1db040)
Stack:  81007c54ad08 81007cf85000 81007cf7e000 81007d1fde00
 81006a289cc0 8033f11f 0287 88000fa8
 81001646a6f8  81007cf85000 81007cf7e000
Call Trace:
 [8033f11f] elv_next_request+0x3f/0x150
 [88000fa8

Re: 2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
 On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
  I guess I should sent these here since it looks like not scsi bug anyway.

 It's stex, right? It seems to have some issues with multiple completions
 of commands, which craps out the block layer of course.

Yes, stex. I'm staying with 2.6.19 in that case since it works fine in that 
version.

So scsi bug ... 8-)
-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22 oops kernel BUG at block/elevator.c:366!

[Arkadiusz Miskiewicz]

On Wednesday 29 of August 2007, Jens Axboe wrote:
 On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
  On Wednesday 29 of August 2007, Jens Axboe wrote:
   On Wed, Aug 29 2007, Arkadiusz Miskiewicz wrote:
I guess I should sent these here since it looks like not scsi bug
anyway.
  
   It's stex, right? It seems to have some issues with multiple
   completions of commands, which craps out the block layer of course.
 
  Yes, stex. I'm staying with 2.6.19 in that case since it works fine in
  that version.
 
  So scsi bug ... 8-)

 And you based that conclusion on what exactly?

Isn't drivers/scsi/* handled by [EMAIL PROTECTED] (that's what I mean)

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: resume from ram much slower

[Arkadiusz Miskiewicz]

On Friday 10 of August 2007, Rafael J. Wysocki wrote:
> On Friday, 10 August 2007 18:48, Arkadiusz Miskiewicz wrote:
> > Hi,
> >
> > Starting 1-2 weeks ago I have very long resume from
> > ram times. It takes more than 1 min to resume. Does anyone see such
> > behaviour?
> >
> > Kernel from yesterday git, thinkpad z60m, suspend.sf.net tools 20070801
> >
> > "ACPI handle has no context!" are interesting btw.
>
> Let's try to find out something.
>
> Please apply the patch below and see if anything changes.

dmesg below. Nothing changes. I guess bisecting is going to be needed.

[   24.913452] tun0: Disabled Privacy Extensions
[   32.069393] eth1: no IPv6 routers present
[   32.975171] ehci_hcd :00:1d.7: remove, state 4
[   32.975182] usb usb1: USB disconnect, address 1
[   33.042655] ehci_hcd :00:1d.7: USB bus 1 deregistered
[   33.043371] ACPI: PCI interrupt for device :00:1d.7 disabled
[   33.045553] uhci_hcd :00:1d.3: remove, state 4
[   33.045563] usb usb5: USB disconnect, address 1
[   33.045899] uhci_hcd :00:1d.3: USB bus 5 deregistered
[   33.045940] ACPI: PCI interrupt for device :00:1d.3 disabled
[   33.056364] uhci_hcd :00:1d.2: remove, state 1
[   33.056527] usb usb4: USB disconnect, address 1
[   33.056618] usb 4-1: USB disconnect, address 2
[   13.345228] usb 4-2: USB disconnect, address 3
[   13.345652] uhci_hcd :00:1d.2: USB bus 4 deregistered
[   13.345725] ACPI: PCI interrupt for device :00:1d.2 disabled
[   13.345778] uhci_hcd :00:1d.1: remove, state 1
[   13.345820] usb usb3: USB disconnect, address 1
[   13.345861] usb 3-1: USB disconnect, address 2
[   13.363517] uhci_hcd :00:1d.1: USB bus 3 deregistered
[   13.368510] ACPI: PCI interrupt for device :00:1d.1 disabled
[   13.370151] uhci_hcd :00:1d.0: remove, state 4
[   13.370207] usb usb2: USB disconnect, address 1
[   13.370420] uhci_hcd :00:1d.0: USB bus 2 deregistered
[   13.371608] ACPI: PCI interrupt for device :00:1d.0 disabled
[   13.886551] Stopping tasks ... done.
[   15.057017] Suspending console(s)
[   15.163956] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   15.164039] sd 0:0:0:0: [sda] Stopping disk
[   39.102495] pnp: Device 00:09 disabled.
[   39.102518] eth1: Going into suspend...
[   39.105275] ACPI: PCI interrupt for device :14:02.0 disabled
[   39.105285] ACPI handle has no context!
[   39.119631] ACPI handle has no context!
[   39.119656] ACPI: PCI interrupt for device :14:00.2 disabled
[   39.119665] ACPI handle has no context!
[   39.136949] ACPI handle has no context!
[   39.290491] ACPI handle has no context!
[   39.310814] ACPI: PCI interrupt for device :00:1b.0 disabled
[0.955410] Intel machine check architecture supported.
[0.955426] Intel machine check reporting enabled on CPU#0.
[0.955447] Back to C!
[0.389962] PM: Writing back config space on device :00:01.0 at offset 
1 (was 100107, writing 100507)
[0.389972] PCI: Setting latency timer of device :00:01.0 to 64
[   44.479003] PM: Writing back config space on device :00:1b.0 at offset 
1 (was 16, writing 12)
[   44.479029] ACPI: PCI Interrupt :00:1b.0[A] -> GSI 16 (level, low) -> 
IRQ 16
[   44.479039] PCI: Setting latency timer of device :00:1b.0 to 64
[   44.587216] PM: Writing back config space on device :00:1c.0 at offset 
1 (was 100107, writing 100507)
[   44.587252] PCI: Setting latency timer of device :00:1c.0 to 64
[   44.587283] PM: Writing back config space on device :00:1c.1 at offset 
1 (was 100107, writing 100507)
[   44.587318] PCI: Setting latency timer of device :00:1c.1 to 64
[   44.587348] PM: Writing back config space on device :00:1c.2 at offset 
1 (was 100107, writing 100507)
[   44.587384] PCI: Setting latency timer of device :00:1c.2 to 64
[   44.587414] PM: Writing back config space on device :00:1c.3 at offset 
1 (was 100107, writing 100507)
[   44.587449] PCI: Setting latency timer of device :00:1c.3 to 64
[   44.587459] PM: Writing back config space on device :00:1d.0 at offset 
f (was 100, writing 10b)
[   44.587488] PM: Writing back config space on device :00:1d.1 at offset 
f (was 200, writing 20b)
[   44.587518] PM: Writing back config space on device :00:1d.2 at offset 
f (was 300, writing 30b)
[   44.587547] PM: Writing back config space on device :00:1d.3 at offset 
f (was 400, writing 40b)
[   44.587582] PM: Writing back config space on device :00:1d.7 at offset 
f (was 400, writing 40b)
[   44.587603] PM: Writing back config space on device :00:1d.7 at offset 
4 (was 0, writing b0004000)
[   44.587614] PM: Writing back config space on device :00:1d.7 at offset 
1 (was 290, writing 2900102)
[   44.587668] PCI: Setting latency timer of device :00:1e.0 to 64
[   44.587882] PM: Writing back config space on device :00:1f.2 at offset 
1 (was 2b5, wr

Re: resume from ram much slower

[Arkadiusz Miskiewicz]

On Friday 10 of August 2007, Rafael J. Wysocki wrote:
 On Friday, 10 August 2007 18:48, Arkadiusz Miskiewicz wrote:
  Hi,
 
  Starting 1-2 weeks ago I have very long resume from
  ram times. It takes more than 1 min to resume. Does anyone see such
  behaviour?
 
  Kernel from yesterday git, thinkpad z60m, suspend.sf.net tools 20070801
 
  ACPI handle has no context! are interesting btw.

 Let's try to find out something.

 Please apply the patch below and see if anything changes.

dmesg below. Nothing changes. I guess bisecting is going to be needed.

[   24.913452] tun0: Disabled Privacy Extensions
[   32.069393] eth1: no IPv6 routers present
[   32.975171] ehci_hcd :00:1d.7: remove, state 4
[   32.975182] usb usb1: USB disconnect, address 1
[   33.042655] ehci_hcd :00:1d.7: USB bus 1 deregistered
[   33.043371] ACPI: PCI interrupt for device :00:1d.7 disabled
[   33.045553] uhci_hcd :00:1d.3: remove, state 4
[   33.045563] usb usb5: USB disconnect, address 1
[   33.045899] uhci_hcd :00:1d.3: USB bus 5 deregistered
[   33.045940] ACPI: PCI interrupt for device :00:1d.3 disabled
[   33.056364] uhci_hcd :00:1d.2: remove, state 1
[   33.056527] usb usb4: USB disconnect, address 1
[   33.056618] usb 4-1: USB disconnect, address 2
[   13.345228] usb 4-2: USB disconnect, address 3
[   13.345652] uhci_hcd :00:1d.2: USB bus 4 deregistered
[   13.345725] ACPI: PCI interrupt for device :00:1d.2 disabled
[   13.345778] uhci_hcd :00:1d.1: remove, state 1
[   13.345820] usb usb3: USB disconnect, address 1
[   13.345861] usb 3-1: USB disconnect, address 2
[   13.363517] uhci_hcd :00:1d.1: USB bus 3 deregistered
[   13.368510] ACPI: PCI interrupt for device :00:1d.1 disabled
[   13.370151] uhci_hcd :00:1d.0: remove, state 4
[   13.370207] usb usb2: USB disconnect, address 1
[   13.370420] uhci_hcd :00:1d.0: USB bus 2 deregistered
[   13.371608] ACPI: PCI interrupt for device :00:1d.0 disabled
[   13.886551] Stopping tasks ... done.
[   15.057017] Suspending console(s)
[   15.163956] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   15.164039] sd 0:0:0:0: [sda] Stopping disk
[   39.102495] pnp: Device 00:09 disabled.
[   39.102518] eth1: Going into suspend...
[   39.105275] ACPI: PCI interrupt for device :14:02.0 disabled
[   39.105285] ACPI handle has no context!
[   39.119631] ACPI handle has no context!
[   39.119656] ACPI: PCI interrupt for device :14:00.2 disabled
[   39.119665] ACPI handle has no context!
[   39.136949] ACPI handle has no context!
[   39.290491] ACPI handle has no context!
[   39.310814] ACPI: PCI interrupt for device :00:1b.0 disabled
[0.955410] Intel machine check architecture supported.
[0.955426] Intel machine check reporting enabled on CPU#0.
[0.955447] Back to C!
[0.389962] PM: Writing back config space on device :00:01.0 at offset 
1 (was 100107, writing 100507)
[0.389972] PCI: Setting latency timer of device :00:01.0 to 64
[   44.479003] PM: Writing back config space on device :00:1b.0 at offset 
1 (was 16, writing 12)
[   44.479029] ACPI: PCI Interrupt :00:1b.0[A] - GSI 16 (level, low) - 
IRQ 16
[   44.479039] PCI: Setting latency timer of device :00:1b.0 to 64
[   44.587216] PM: Writing back config space on device :00:1c.0 at offset 
1 (was 100107, writing 100507)
[   44.587252] PCI: Setting latency timer of device :00:1c.0 to 64
[   44.587283] PM: Writing back config space on device :00:1c.1 at offset 
1 (was 100107, writing 100507)
[   44.587318] PCI: Setting latency timer of device :00:1c.1 to 64
[   44.587348] PM: Writing back config space on device :00:1c.2 at offset 
1 (was 100107, writing 100507)
[   44.587384] PCI: Setting latency timer of device :00:1c.2 to 64
[   44.587414] PM: Writing back config space on device :00:1c.3 at offset 
1 (was 100107, writing 100507)
[   44.587449] PCI: Setting latency timer of device :00:1c.3 to 64
[   44.587459] PM: Writing back config space on device :00:1d.0 at offset 
f (was 100, writing 10b)
[   44.587488] PM: Writing back config space on device :00:1d.1 at offset 
f (was 200, writing 20b)
[   44.587518] PM: Writing back config space on device :00:1d.2 at offset 
f (was 300, writing 30b)
[   44.587547] PM: Writing back config space on device :00:1d.3 at offset 
f (was 400, writing 40b)
[   44.587582] PM: Writing back config space on device :00:1d.7 at offset 
f (was 400, writing 40b)
[   44.587603] PM: Writing back config space on device :00:1d.7 at offset 
4 (was 0, writing b0004000)
[   44.587614] PM: Writing back config space on device :00:1d.7 at offset 
1 (was 290, writing 2900102)
[   44.587668] PCI: Setting latency timer of device :00:1e.0 to 64
[   44.587882] PM: Writing back config space on device :00:1f.2 at offset 
1 (was 2b5, writing 2b80005)
[   44.587905] PCI: Setting latency timer of device :00:1f.2 to 64
[   44.588290] ACPI: PCI

Re: resume from ram much slower

[Arkadiusz Miskiewicz]

On Friday 10 of August 2007, Rafael J. Wysocki wrote:
> On Friday, 10 August 2007 19:34, Michal Piotrowski wrote:
> > [S-T-R wizards CC'ed]
> >
> > On 10/08/07, Arkadiusz Miskiewicz <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > Starting 1-2 weeks ago I have very long resume from
> > > ram times. It takes more than 1 min to resume. Does anyone see such
> > > behaviour?
>
> No.
>
> Did it start after 2.6.23-rc1?

I'm almost sure that it was after rc1. Unfortunately I'm doing git pull too 
often so cannot be 100% sure.

> Greetings,
> Rafael



-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: resume from ram much slower

[Arkadiusz Miskiewicz]

On Friday 10 of August 2007, Rafael J. Wysocki wrote:
 On Friday, 10 August 2007 19:34, Michal Piotrowski wrote:
  [S-T-R wizards CC'ed]
 
  On 10/08/07, Arkadiusz Miskiewicz [EMAIL PROTECTED] wrote:
   Hi,
  
   Starting 1-2 weeks ago I have very long resume from
   ram times. It takes more than 1 min to resume. Does anyone see such
   behaviour?

 No.

 Did it start after 2.6.23-rc1?

I'm almost sure that it was after rc1. Unfortunately I'm doing git pull too 
often so cannot be 100% sure.

 Greetings,
 Rafael



-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

very big device. try to use READ CAPACITY(16)

[Arkadiusz Miskiewicz]

Hello,

What does "very big device. try to use READ CAPACITY(16)" mean for user? Is 
this advice for driver developer or for user (if for user then what does it 
mean exactly) ?


sdc : very big device. try to use READ CAPACITY(16).
SCSI device sdc: 4823210240 512-byte hdwr sectors (2469484 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 12 00 00
SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
sdc : very big device. try to use READ CAPACITY(16).
SCSI device sdc: 4823210240 512-byte hdwr sectors (2469484 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 12 00 00
SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdc: unknown partition table
sd 0:2:0:0: Attached scsi disk sdc

2.6.21.6, stex driver

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

very big device. try to use READ CAPACITY(16)

[Arkadiusz Miskiewicz]

Hello,

What does very big device. try to use READ CAPACITY(16) mean for user? Is 
this advice for driver developer or for user (if for user then what does it 
mean exactly) ?


sdc : very big device. try to use READ CAPACITY(16).
SCSI device sdc: 4823210240 512-byte hdwr sectors (2469484 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 12 00 00
SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
sdc : very big device. try to use READ CAPACITY(16).
SCSI device sdc: 4823210240 512-byte hdwr sectors (2469484 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 12 00 00
SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sdc: unknown partition table
sd 0:2:0:0: Attached scsi disk sdc

2.6.21.6, stex driver

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23rc1 git: EIP is at acpi_processor_throttling_seq_show+0x8b/0xdd [processor]

[Arkadiusz Miskiewicz]

On Monday 23 of July 2007, Len Brown wrote:
> On Monday 23 July 2007 11:40, Arkadiusz Miskiewicz wrote:
> > After booting fresh 2.6.23rc1 taken from git I noticed oops in dmesg:
> >
> > [   46.274038] BUG: unable to handle kernel NULL pointer dereference at
> > virtual address  [   46.274042]  printing eip:
> > [   46.274044] f8b5b2dc
> > [   46.274045] *pde = 
> > [   46.274048] Oops:  [#1]
[...]
>
> Please try the patch below -- seems that I somehow neglected to include it
> in my rc1 batch.

No oops with patch applied. Thanks!

>
> thanks,
> -Len
>
> Subject: fix oops due to typo in new throttling code
> From: Luming Yu <[EMAIL PROTECTED]>
>
>
> Signed-off-by: Luming Yu <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Len Brown <[EMAIL PROTECTED]>
>
> ---
>
>  drivers/acpi/processor_throttling.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
>
> Index: linus/drivers/acpi/processor_throttling.c
> ===
> --- linus.orig/drivers/acpi/processor_throttling.c
> +++ linus/drivers/acpi/processor_throttling.c
> @@ -658,18 +658,20 @@ static int acpi_processor_throttling_seq
>  pr->throttling.state_count - 1);
>
>   seq_puts(seq, "states:\n");
> - if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
> + if (pr->throttling.acpi_processor_get_throttling ==
> + acpi_processor_get_throttling_fadt) {
>   for (i = 0; i < pr->throttling.state_count; i++)
>   seq_printf(seq, "   %cT%d:  %02d%%\n",
>  (i == pr->throttling.state ? '*' : ' '), i,
>  (pr->throttling.states[i].performance ? pr->
>   throttling.states[i].performance / 10 : 0));
> - else
> + } else {
>   for (i = 0; i < pr->throttling.state_count; i++)
>   seq_printf(seq, "   %cT%d:  %02d%%\n",
>  (i == pr->throttling.state ? '*' : ' '), i,
>  (int)pr->throttling.states_tss[i].
>  freqpercentage);
> + }
>
>end:
>   return 0;



-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23rc1 git: EIP is at acpi_processor_throttling_seq_show+0x8b/0xdd [processor]

[Arkadiusz Miskiewicz]

On Monday 23 of July 2007, Len Brown wrote:
 On Monday 23 July 2007 11:40, Arkadiusz Miskiewicz wrote:
  After booting fresh 2.6.23rc1 taken from git I noticed oops in dmesg:
 
  [   46.274038] BUG: unable to handle kernel NULL pointer dereference at
  virtual address  [   46.274042]  printing eip:
  [   46.274044] f8b5b2dc
  [   46.274045] *pde = 
  [   46.274048] Oops:  [#1]
[...]

 Please try the patch below -- seems that I somehow neglected to include it
 in my rc1 batch.

No oops with patch applied. Thanks!


 thanks,
 -Len

 Subject: fix oops due to typo in new throttling code
 From: Luming Yu [EMAIL PROTECTED]


 Signed-off-by: Luming Yu [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]
 Signed-off-by: Len Brown [EMAIL PROTECTED]

 ---

  drivers/acpi/processor_throttling.c |6 --
  1 files changed, 4 insertions(+), 2 deletions(-)

 Index: linus/drivers/acpi/processor_throttling.c
 ===
 --- linus.orig/drivers/acpi/processor_throttling.c
 +++ linus/drivers/acpi/processor_throttling.c
 @@ -658,18 +658,20 @@ static int acpi_processor_throttling_seq
  pr-throttling.state_count - 1);

   seq_puts(seq, states:\n);
 - if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
 + if (pr-throttling.acpi_processor_get_throttling ==
 + acpi_processor_get_throttling_fadt) {
   for (i = 0; i  pr-throttling.state_count; i++)
   seq_printf(seq,%cT%d:  %02d%%\n,
  (i == pr-throttling.state ? '*' : ' '), i,
  (pr-throttling.states[i].performance ? pr-
   throttling.states[i].performance / 10 : 0));
 - else
 + } else {
   for (i = 0; i  pr-throttling.state_count; i++)
   seq_printf(seq,%cT%d:  %02d%%\n,
  (i == pr-throttling.state ? '*' : ' '), i,
  (int)pr-throttling.states_tss[i].
  freqpercentage);
 + }

end:
   return 0;



-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: clocksource tsc unstable

[Arkadiusz Miskiewicz]

On Monday 09 of July 2007, Arnaldo Carvalho de Melo wrote:
> Renato S. Yamane wrote:
> > On Kernel 2.6.21.6 I see this message in dmesg:
> > Clocksource tsc unstable (delta = 732182695 ns)
> >
> > It's normal?
>
> AMD CPU? SMP? Details, please.

Here (after resume from ram btw):
[   10.726665] Marking TSC unstable due to: possible TSC halt in C2.
[   47.203328] Clocksource tsc unstable (delta = -198170415 ns)

2.6.22 #77 Mon Jul 9 09:14:25 CEST 2007 i686

vendor_id   : GenuineIntel
cpu family  : 6
model   : 13
model name  : Intel(R) Pentium(R) M processor 2.00GHz


It's thinkpad z60m.

> - Arnaldo

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: clocksource tsc unstable

[Arkadiusz Miskiewicz]

On Monday 09 of July 2007, Arnaldo Carvalho de Melo wrote:
 Renato S. Yamane wrote:
  On Kernel 2.6.21.6 I see this message in dmesg:
  Clocksource tsc unstable (delta = 732182695 ns)
 
  It's normal?

 AMD CPU? SMP? Details, please.

Here (after resume from ram btw):
[   10.726665] Marking TSC unstable due to: possible TSC halt in C2.
[   47.203328] Clocksource tsc unstable (delta = -198170415 ns)

2.6.22 #77 Mon Jul 9 09:14:25 CEST 2007 i686

vendor_id   : GenuineIntel
cpu family  : 6
model   : 13
model name  : Intel(R) Pentium(R) M processor 2.00GHz


It's thinkpad z60m.

 - Arnaldo

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arkadiusz Miskiewicz]

On Saturday 23 of June 2007, Andi Kleen wrote:
> On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > Here's a nickel. Get yourself a real shell.
> >
> > POSIX compilant shell isn't real shell?
>
> In this case it's not good enough. We're not writing POSIX portable
> software here, but Linux software where /bin/sh is /bin/bash.

Here on my Linux software /bin/sh is pdksh and bash installation is 
*optional*.

Is it so hard to tell truth in first line of shell script, tha it NEEDS 
exactly bash (#!/bin/bash) ?

> -Andi

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arkadiusz Miskiewicz]

On Saturday 23 of June 2007, Andi Kleen wrote:
> Here's a nickel. Get yourself a real shell.

POSIX compilant shell isn't real shell?

> -Andi

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arkadiusz Miskiewicz]

On Saturday 23 of June 2007, Andi Kleen wrote:
 Here's a nickel. Get yourself a real shell.

POSIX compilant shell isn't real shell?

 -Andi

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arkadiusz Miskiewicz]

On Saturday 23 of June 2007, Andi Kleen wrote:
 On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
  On Saturday 23 of June 2007, Andi Kleen wrote:
   Here's a nickel. Get yourself a real shell.
 
  POSIX compilant shell isn't real shell?

 In this case it's not good enough. We're not writing POSIX portable
 software here, but Linux software where /bin/sh is /bin/bash.

Here on my Linux software /bin/sh is pdksh and bash installation is 
*optional*.

Is it so hard to tell truth in first line of shell script, tha it NEEDS 
exactly bash (#!/bin/bash) ?

 -Andi

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cat /dev/snapshot == OOPs

[Arkadiusz Miskiewicz]

On Sunday 10 of June 2007, Rafael J. Wysocki wrote:

> >
> > [54498.464550] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12)
> > initialised: [EMAIL PROTECTED]
> > [56592.077674] swsusp: Basic memory bitmaps created
> > [56592.084340] BUG: unable to handle kernel NULL pointer dereference at
> > virtual address 000c
>
> Can you please try the appended patch?

[EMAIL PROTECTED] ~]# LC_ALL=C cat /dev/snapshot
cat: /dev/snapshot: No data available

[  237.939976] swsusp: Basic memory bitmaps created
[  237.956642] swsusp: Basic memory bitmaps freed

no oops with that patch.

> Rafael


-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

cat /dev/snapshot == OOPs

[Arkadiusz Miskiewicz]

Hello,

Is this desired behaviour?

$ sudo cat /dev/snapshot

ended with:

[54498.464550] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: 
[EMAIL PROTECTED]
[56592.077674] swsusp: Basic memory bitmaps created
[56592.084340] BUG: unable to handle kernel NULL pointer dereference at 
virtual address 000c
[56592.084340]  printing eip:
[56592.084340] c0135a6e
[56592.084340] *pde = 
[56592.084340] Oops:  [#1]
[56592.084340] Modules linked in: dm_snapshot dm_mod radeon drm binfmt_misc 
ipv6 sch_sfq mmc_block rfcomm l2cap bluetooth ircomm_tty ircomm 
cpufreq_ondemand acpi_cpufreq freq_table hdaps snd_pcm_oss snd_mixer_oss 
video thermal processor fan container evdev button battery ac nvram 
thinkpad_acpi hwmon backlight tun capability commoncap firewire_ohci 
firewire_core crc_itu_t ahci pcmcia sdhci usbhid hid ff_memless ohci1394 
mmc_core ata_generic ipw2200 ieee80211 ieee80211_crypt firmware_class 
ieee1394 yenta_socket rsrc_nonstatic pcmcia_core nsc_ircc tg3 snd_hda_intel 
generic i2c_i801 i2c_core ide_core snd_pcm snd_timer snd intel_agp iTCO_wdt 
iTCO_vendor_support soundcore sr_mod psmouse agpgart snd_page_alloc serio_raw 
uhci_hcd irda crc_ccitt ehci_hcd usbcore cdrom rtc_cmos rtc_core rtc_lib xfs 
scsi_wait_scan sd_mod ata_piix libata scsi_mod
[56592.084340] CPU:0
[56592.084340] EIP:0060:[]Not tainted VLI
[56592.084340] EFLAGS: 00210206   (2.6.22-rc4 #70)
[56592.084340] EIP is at snapshot_read_next+0xcf/0x1d7
[56592.084340] eax:    ebx: d96fd200   ecx: c038e8f8   edx: e0688000
[56592.084340] esi: c031c462   edi: e0688186   ebp: ee42df5c   esp: ee42df48
[56592.084340] ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
[56592.084340] Process cat (pid: 22965, ti=ee42c000 task=c7d55480 
task.ti=ee42c000)
[56592.084340] Stack: 1000 c038e8f8 d96fd200 c038e8f8 0804e000 ee42df70 
c0136ba5 d96fd200
[56592.084340]c0136b91 0804e000 ee42df90 c015b26b ee42df9c 0006 
1000 d96fd200
[56592.084340]fff7 0804e000 ee42dfb0 c015b5d3 ee42df9c  
 
[56592.084340] Call Trace:
[56592.084340]  [] show_trace_log_lvl+0x1a/0x2f
[56592.084340]  [] show_stack_log_lvl+0x9b/0xa3
[56592.084340]  [] show_registers+0x1b4/0x286
[56592.084340]  [] die+0xdf/0x1b1
[56592.084340]  [] do_page_fault+0x424/0x4f0
[56592.084340]  [] error_code+0x6a/0x70
[56592.084340]  [] snapshot_read+0x14/0x48
[56592.084340]  [] vfs_read+0xad/0x15f
[56592.084340]  [] sys_read+0x3d/0x61
[56592.084340]  [] sysenter_past_esp+0x5f/0x85
[56592.084340]  ===
[56592.084340] Code: 03 05 b4 e8 38 c0 40 89 82 98 01 00 00 c1 e0 0c 89 82 9c 
01 00 00 a1 a0 e8 38 c0 8b 4d f0 89 41 14 a1 b8 e8 38 c0 a3 c0 e8 38 c0 <8b> 
40 0c c7 05 c8 e8 38 c0 00 00 00 00 c7 05 cc e8 38 c0 ff ff
[56592.084340] EIP: [] snapshot_read_next+0xcf/0x1d7 SS:ESP 
0068:ee42df48
[56592.101007] swsusp: Basic memory bitmaps freed


that's on i686 with git tree with latest commit: 
845a2fdcbd5bc5b9f652201ee95c825827a1d521

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

cat /dev/snapshot == OOPs

[Arkadiusz Miskiewicz]

Hello,

Is this desired behaviour?

$ sudo cat /dev/snapshot

ended with:

[54498.464550] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: 
[EMAIL PROTECTED]
[56592.077674] swsusp: Basic memory bitmaps created
[56592.084340] BUG: unable to handle kernel NULL pointer dereference at 
virtual address 000c
[56592.084340]  printing eip:
[56592.084340] c0135a6e
[56592.084340] *pde = 
[56592.084340] Oops:  [#1]
[56592.084340] Modules linked in: dm_snapshot dm_mod radeon drm binfmt_misc 
ipv6 sch_sfq mmc_block rfcomm l2cap bluetooth ircomm_tty ircomm 
cpufreq_ondemand acpi_cpufreq freq_table hdaps snd_pcm_oss snd_mixer_oss 
video thermal processor fan container evdev button battery ac nvram 
thinkpad_acpi hwmon backlight tun capability commoncap firewire_ohci 
firewire_core crc_itu_t ahci pcmcia sdhci usbhid hid ff_memless ohci1394 
mmc_core ata_generic ipw2200 ieee80211 ieee80211_crypt firmware_class 
ieee1394 yenta_socket rsrc_nonstatic pcmcia_core nsc_ircc tg3 snd_hda_intel 
generic i2c_i801 i2c_core ide_core snd_pcm snd_timer snd intel_agp iTCO_wdt 
iTCO_vendor_support soundcore sr_mod psmouse agpgart snd_page_alloc serio_raw 
uhci_hcd irda crc_ccitt ehci_hcd usbcore cdrom rtc_cmos rtc_core rtc_lib xfs 
scsi_wait_scan sd_mod ata_piix libata scsi_mod
[56592.084340] CPU:0
[56592.084340] EIP:0060:[c0135a6e]Not tainted VLI
[56592.084340] EFLAGS: 00210206   (2.6.22-rc4 #70)
[56592.084340] EIP is at snapshot_read_next+0xcf/0x1d7
[56592.084340] eax:    ebx: d96fd200   ecx: c038e8f8   edx: e0688000
[56592.084340] esi: c031c462   edi: e0688186   ebp: ee42df5c   esp: ee42df48
[56592.084340] ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
[56592.084340] Process cat (pid: 22965, ti=ee42c000 task=c7d55480 
task.ti=ee42c000)
[56592.084340] Stack: 1000 c038e8f8 d96fd200 c038e8f8 0804e000 ee42df70 
c0136ba5 d96fd200
[56592.084340]c0136b91 0804e000 ee42df90 c015b26b ee42df9c 0006 
1000 d96fd200
[56592.084340]fff7 0804e000 ee42dfb0 c015b5d3 ee42df9c  
 
[56592.084340] Call Trace:
[56592.084340]  [c0104a50] show_trace_log_lvl+0x1a/0x2f
[56592.084340]  [c0104b00] show_stack_log_lvl+0x9b/0xa3
[56592.084340]  [c0104cbc] show_registers+0x1b4/0x286
[56592.084340]  [c0104e6d] die+0xdf/0x1b1
[56592.084340]  [c01148a0] do_page_fault+0x424/0x4f0
[56592.084340]  [c027f90a] error_code+0x6a/0x70
[56592.084340]  [c0136ba5] snapshot_read+0x14/0x48
[56592.084340]  [c015b26b] vfs_read+0xad/0x15f
[56592.084340]  [c015b5d3] sys_read+0x3d/0x61
[56592.084340]  [c0103b8a] sysenter_past_esp+0x5f/0x85
[56592.084340]  ===
[56592.084340] Code: 03 05 b4 e8 38 c0 40 89 82 98 01 00 00 c1 e0 0c 89 82 9c 
01 00 00 a1 a0 e8 38 c0 8b 4d f0 89 41 14 a1 b8 e8 38 c0 a3 c0 e8 38 c0 8b 
40 0c c7 05 c8 e8 38 c0 00 00 00 00 c7 05 cc e8 38 c0 ff ff
[56592.084340] EIP: [c0135a6e] snapshot_read_next+0xcf/0x1d7 SS:ESP 
0068:ee42df48
[56592.101007] swsusp: Basic memory bitmaps freed


that's on i686 with git tree with latest commit: 
845a2fdcbd5bc5b9f652201ee95c825827a1d521

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cat /dev/snapshot == OOPs

[Arkadiusz Miskiewicz]

On Sunday 10 of June 2007, Rafael J. Wysocki wrote:

 
  [54498.464550] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12)
  initialised: [EMAIL PROTECTED]
  [56592.077674] swsusp: Basic memory bitmaps created
  [56592.084340] BUG: unable to handle kernel NULL pointer dereference at
  virtual address 000c

 Can you please try the appended patch?

[EMAIL PROTECTED] ~]# LC_ALL=C cat /dev/snapshot
cat: /dev/snapshot: No data available

[  237.939976] swsusp: Basic memory bitmaps created
[  237.956642] swsusp: Basic memory bitmaps freed

no oops with that patch.

 Rafael


-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: networking busted in current -git ???

[Arkadiusz Miskiewicz]

On Friday 08 of June 2007, you wrote:
> Hello,
>
> I am using the current git tree: 85f6038f2170e3335dda09c3dfb0f83110e87019 .
> Git tree from two days ago (with the same config) works fine.
>
> Attempting to acquire an IP address via DHCP fails with:
>
> SIOCSIFADDR: No buffer space available
> Listening on LPF/eth0/00:19:b9:0c:9a:43
> Sending on   LPF/eth0/00:19:b9:0c:9a:43
> Sending on   Socket/fallback
> DHCPREQUEST on eth0 to 255.255.255.255 port 67
> DHCPACK from xxx.xxx.xxx.xxx
> SIOCSIFADDR: No buffer space available
> SIOCSIFNETMASK: Cannot assign requested address
> SIOCSIFBRDADDR: Cannot assign requested address
> SIOCADDRT: Network is unreachable
> bound to xxx.xxx.xxx.xxx -- renewal in 98610 seconds.
>
> This is on a Dell 490 with tg3 network driver running Ubuntu 7.04 .
> .config and dmesg are appended.
>
> florin

Here it requires few retries (stop dhcpcd, start again) to get the IP. git 
tree from few hours ago. tg3 driver. I also saw SIOCSIFADDR: No buffer space 
available once.

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: networking busted in current -git ???

[Arkadiusz Miskiewicz]

On Friday 08 of June 2007, you wrote:
 Hello,

 I am using the current git tree: 85f6038f2170e3335dda09c3dfb0f83110e87019 .
 Git tree from two days ago (with the same config) works fine.

 Attempting to acquire an IP address via DHCP fails with:

 SIOCSIFADDR: No buffer space available
 Listening on LPF/eth0/00:19:b9:0c:9a:43
 Sending on   LPF/eth0/00:19:b9:0c:9a:43
 Sending on   Socket/fallback
 DHCPREQUEST on eth0 to 255.255.255.255 port 67
 DHCPACK from xxx.xxx.xxx.xxx
 SIOCSIFADDR: No buffer space available
 SIOCSIFNETMASK: Cannot assign requested address
 SIOCSIFBRDADDR: Cannot assign requested address
 SIOCADDRT: Network is unreachable
 bound to xxx.xxx.xxx.xxx -- renewal in 98610 seconds.

 This is on a Dell 490 with tg3 network driver running Ubuntu 7.04 .
 .config and dmesg are appended.

 florin

Here it requires few retries (stop dhcpcd, start again) to get the IP. git 
tree from few hours ago. tg3 driver. I also saw SIOCSIFADDR: No buffer space 
available once.

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Arkadiusz Miskiewicz]

On Sunday 29 of April 2007, Tomasz Chmielewski wrote:

> > I reported a bug that eats people's hard disks due to a bug
> > in the X.ORG PCI support code on sparc, NOBODY has fixed
> > the bug in 2 years even though a full bugzilla entry with
> > even a full patch fix is in there.
>
> And how fast was the bug fixed when you posted it to the X.ORG list?

Not so long ago I got such reply on xorg@ ml:

,,Sorry, without a bugzilla entry, I lost your bug report. ''

xorg people want bugzilla reports (well, they don't fix them anyway, too).

-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/