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

0 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: > > > > > H

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

0 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: > > > > > H

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

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] [

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

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] [

stack gap fix for 4.1

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

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)

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

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

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

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

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:

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

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:

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

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

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

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

Re: OOM detection regressions since 4.7

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

Re: OOM detection regressions since 4.7

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 > > > >

Re: Linux 4.1.28

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: >

Re: Linux 4.1.28

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: >

Re: Linux 4.1.28

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

Re: Linux 4.1.28

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

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

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: >

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

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

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

[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. > >>

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

[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

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

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 wi

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

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

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

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 [

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

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 [

Re: [Bug 3.14.17] inconsistent lock state

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. >

Re: [Bug 3.14.17] inconsistent lock state

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

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

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:

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

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

Re: Support for netconsole as default tty/console?

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, >

Re: Support for netconsole as default tty/console?

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

Re: kernel bugzilla #64531: intel microcode information

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

Re: kernel bugzilla #64531: intel microcode information

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,

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

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 >

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

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

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

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

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

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 @@

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

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

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

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),

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

erence 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 domai

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

. 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

Re: 3.8.3 and 3.9git occasional watchdog oops

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

Re: 3.8.3 and 3.9git occasional watchdog oops

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

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

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 ge

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

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

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

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)

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

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

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

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 +

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

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 +

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

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

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

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, Arkadiu

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

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

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

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

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

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 conne

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: git guidance

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

Re: git guidance

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

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

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

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

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 ? > >

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

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

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

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

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

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

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

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.

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

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 ? > > >

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

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:

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

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

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

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 li

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

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 c

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

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

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

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

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

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

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

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

Re: resume from ram much slower

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 > &g

Re: resume from ram much slower

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

Re: resume from ram much slower

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

Re: resume from ram much slower

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

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

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)

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

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)

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

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 > &g

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

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

Re: clocksource tsc unstable

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]

Re: clocksource tsc unstable

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

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

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? > &g

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

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

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

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

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

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

Re: cat /dev/snapshot == OOPs

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 > >

cat /dev/snapshot == OOPs

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

cat /dev/snapshot == OOPs

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

Re: cat /dev/snapshot == OOPs

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

Re: networking busted in current -git ???

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 >

Re: networking busted in current -git ???

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

Re: Linux 2.6.21

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

  1   2   >