Re: [PATCH 12/12] watchdog: sp5100_tco: Add support for recent FCH versions

I'm trying to remove non-ASCII chars from the mail body in the hope it reaches the lists... My ISP still adds that X-Spam-Report: header quoting large part of the mail body without MIME-encoding it. On 2018-01-04 20:21, Guenter Roeck wrote: On Thu, Jan 04, 2018 at 01:01:22PM +0100, Boszormenyi

Re: [PATCH 12/12] watchdog: sp5100_tco: Add support for recent FCH versions

I'm trying to remove non-ASCII chars from the mail body in the hope it reaches the lists... My ISP still adds that X-Spam-Report: header quoting large part of the mail body without MIME-encoding it. On 2018-01-04 20:21, Guenter Roeck wrote: On Thu, Jan 04, 2018 at 01:01:22PM +0100, Boszormenyi

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

Hi, On 2017-08-22 11:33, Benjamin Tissoires wrote: On Aug 11 2017 or thereabouts, JamChen wrote: From: Jam Chen The vendor used the same PID(0x0001) for multiple touch IC controllers. The newer ICs can support HID class and report the multitouch collection in the

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

Hi, On 2017-08-22 11:33, Benjamin Tissoires wrote: On Aug 11 2017 or thereabouts, JamChen wrote: From: Jam Chen The vendor used the same PID(0x0001) for multiple touch IC controllers. The newer ICs can support HID class and report the multitouch collection in the descriptor. So they were

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

2017-08-17 13:08 keltezéssel, JiaMing Chen írta: Hi Zoltán, Is it the panel orientation issue? If you run the position calibration using the tslib, can it be fixed? Best regards, Jam Chen 2017-08-15 17:43 GMT+08:00 Boszormenyi Zoltan <zbos...@pr.hu <mailto:zbos...@pr.hu>>: Hi

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

2017-08-17 13:08 keltezéssel, JiaMing Chen írta: Hi Zoltán, Is it the panel orientation issue? If you run the position calibration using the tslib, can it be fixed? Best regards, Jam Chen 2017-08-15 17:43 GMT+08:00 Boszormenyi Zoltan mailto:zbos...@pr.hu>>: Hi, 2017-08-11

ACPI: IRQ x override to edge, high

Hi, on two different Intel based POS machines where UARTs are crucial, I see such messages (4.11.7 now, seen with older kernels, too): [0.919239] ACPI: IRQ 4 override to edge, high [0.919334] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) [0.919697] ACPI: IRQ 3 override

ACPI: IRQ x override to edge, high

Hi, on two different Intel based POS machines where UARTs are crucial, I see such messages (4.11.7 now, seen with older kernels, too): [0.919239] ACPI: IRQ 4 override to edge, high [0.919334] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active) [0.919697] ACPI: IRQ 3 override

Re: [PATCH 5/5 v4] watchdog: sp5100_tco: Use request_declared_muxed_region()

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: Use the new request_declared_muxed_region() macro to synchronize accesses to the SB800 I/O port pair (0xcd6 / 0xcd7) with the PCI quirk for isochronous USB transfers and with the i2c-piix4 driver. At the same time, remove the long lifetime

Re: [PATCH 5/5 v4] watchdog: sp5100_tco: Use request_declared_muxed_region()

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: Use the new request_declared_muxed_region() macro to synchronize accesses to the SB800 I/O port pair (0xcd6 / 0xcd7) with the PCI quirk for isochronous USB transfers and with the i2c-piix4 driver. At the same time, remove the long lifetime

Re: [PATCH 3/5 v4] usb: pci-quirks: Protect the I/O port pair of SB800

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: This patch uses the previously introduced macro called request_declared_muxed_region() to synchronize access to the I/O port pair 0xcd6 / 0xcd7 on SB800. These I/O ports are also used by i2c-piix4 and sp5100_tco, so synchronization is

Re: [PATCH 3/5 v4] usb: pci-quirks: Protect the I/O port pair of SB800

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: This patch uses the previously introduced macro called request_declared_muxed_region() to synchronize access to the I/O port pair 0xcd6 / 0xcd7 on SB800. These I/O ports are also used by i2c-piix4 and sp5100_tco, so synchronization is

Re: [PATCH 1/5 v2] Extend the request_region() infrastructure

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: Add a new IORESOURCE_ALLOCATED flag that is automatically used when alloc_resource() is used internally in kernel/resource.c and free_resource() now takes this flag into account. The core of __request_region() was factored out into a new

Re: [PATCH 1/5 v2] Extend the request_region() infrastructure

2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: Add a new IORESOURCE_ALLOCATED flag that is automatically used when alloc_resource() is used internally in kernel/resource.c and free_resource() now takes this flag into account. The core of __request_region() was factored out into a new

Re: [PATCH 0/5 v4] Fix sp5100_tco watchdog driver regression

Hi, ping for the series. Adding Greg Kroah-Hartman to the cc: list, both for the USB core and stable series maintainership. 2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: This patch series fixes a regression introduced by: commit 2fee61d22e606fc99ade9079fda15fdee83ec33e Author:

Re: [PATCH 0/5 v4] Fix sp5100_tco watchdog driver regression

Hi, ping for the series. Adding Greg Kroah-Hartman to the cc: list, both for the USB core and stable series maintainership. 2017-06-22 15:21 keltezéssel, Zoltán Böszörményi írta: This patch series fixes a regression introduced by: commit 2fee61d22e606fc99ade9079fda15fdee83ec33e Author:

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

2017-04-03 09:59 keltezéssel, Boszormenyi Zoltan írta: Hi, 2017-04-03 08:34 keltezéssel, Paul Menzel írta: Dear Zoltán, Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: […] and have split the patch into three pieces now (USB quirks, i2c-piix4 and sp5100_tco

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

2017-04-03 09:59 keltezéssel, Boszormenyi Zoltan írta: Hi, 2017-04-03 08:34 keltezéssel, Paul Menzel írta: Dear Zoltán, Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: […] and have split the patch into three pieces now (USB quirks, i2c-piix4 and sp5100_tco

Re: KMS question

2017-04-13 18:20 keltezéssel, Ville Syrjälä írta: On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote: On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher <alexdeuc...@gmail.com> wrote: On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote: 2017-04-13 16:05

Re: KMS question

2017-04-13 18:20 keltezéssel, Ville Syrjälä írta: On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote: On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher wrote: On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: 2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13

Re: KMS question

2017-04-13 17:36 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote: 2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote: Hi, how can I disable t

Re: KMS question

2017-04-13 17:36 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: 2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all

Re: KMS question

2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan <zbos...@pr.hu> wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 8

Re: KMS question

2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor

KMS question

Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens,

KMS question

Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens,

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

Hi, 2017-04-03 08:34 keltezéssel, Paul Menzel írta: Dear Zoltán, Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: […] and have split the patch into three pieces now (USB quirks, i2c-piix4 and sp5100_tco) and they were sent to the relevant mailing lists. Could you

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

Hi, 2017-04-03 08:34 keltezéssel, Paul Menzel írta: Dear Zoltán, Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: […] and have split the patch into three pieces now (USB quirks, i2c-piix4 and sp5100_tco) and they were sent to the relevant mailing lists. Could you

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

2017-04-01 18:20 keltezéssel, Boszormenyi Zoltan írta: The best clean alternative would be add new resource handling infrastructure. * Expose the currently static alloc_resource() in kernel/resource.c With this, driver initialization can allocate the resource once for the lifetime

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

2017-04-01 18:20 keltezéssel, Boszormenyi Zoltan írta: The best clean alternative would be add new resource handling infrastructure. * Expose the currently static alloc_resource() in kernel/resource.c With this, driver initialization can allocate the resource once for the lifetime

Re: [PATCH 1/3] usb: pci-quirks: Add a header for SB800 I/O ports and mutex for locking

2017-04-01 16:40 keltezéssel, Alan Stern írta: On Sat, 1 Apr 2017, Greg KH wrote: On Sat, Apr 01, 2017 at 01:02:21PM +0200, Zoltan Boszormenyi wrote: From: B�sz�rm�nyi Zolt�n This patch adds: * a mutex in the USB PCI quirks code for synchronizing access to the I/O ports on

Re: [PATCH 1/3] usb: pci-quirks: Add a header for SB800 I/O ports and mutex for locking

2017-04-01 16:40 keltezéssel, Alan Stern írta: On Sat, 1 Apr 2017, Greg KH wrote: On Sat, Apr 01, 2017 at 01:02:21PM +0200, Zoltan Boszormenyi wrote: From: B�sz�rm�nyi Zolt�n This patch adds: * a mutex in the USB PCI quirks code for synchronizing access to the I/O ports on SB800 * a new

Re: [PATCH 1/3] usb: pci-quirks: Add a header for SB800 I/O ports and mutex for locking

2017-04-01 15:59 keltezéssel, Greg KH írta: On Sat, Apr 01, 2017 at 01:02:21PM +0200, Zoltan Boszormenyi wrote: From: Böszörményi Zoltán This patch adds: * a mutex in the USB PCI quirks code for synchronizing access to the I/O ports on SB800 * a new header that contains

Re: [PATCH 1/3] usb: pci-quirks: Add a header for SB800 I/O ports and mutex for locking

2017-04-01 15:59 keltezéssel, Greg KH írta: On Sat, Apr 01, 2017 at 01:02:21PM +0200, Zoltan Boszormenyi wrote: From: Böszörményi Zoltán This patch adds: * a mutex in the USB PCI quirks code for synchronizing access to the I/O ports on SB800 * a new header that contains symbols for the

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

2017-03-31 17:05 keltezéssel, Guenter Roeck írta: On Fri, Mar 31, 2017 at 04:46:02PM +0200, Boszormenyi Zoltan wrote: 2017-03-31 14:49 keltezéssel, Guenter Roeck írta: request_muxed_region() can fail, and literally every other driver using it checks for that failure. Please do the same

Re: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

2017-03-31 17:05 keltezéssel, Guenter Roeck írta: On Fri, Mar 31, 2017 at 04:46:02PM +0200, Boszormenyi Zoltan wrote: 2017-03-31 14:49 keltezéssel, Guenter Roeck írta: request_muxed_region() can fail, and literally every other driver using it checks for that failure. Please do the same

[PATCH] watchdog/sp5100_tco: Coexist with i2c-piix

Hi, the attached patch fixes a long time regression in sp5100_tco caused by changes in i2c-piix4. See: https://bugzilla.redhat.com/show_bug.cgi?id=1406844 https://bugzilla.kernel.org/show_bug.cgi?id=170741 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853122 Best regards, Zoltán

[PATCH] watchdog/sp5100_tco: Coexist with i2c-piix

Hi, the attached patch fixes a long time regression in sp5100_tco caused by changes in i2c-piix4. See: https://bugzilla.redhat.com/show_bug.cgi?id=1406844 https://bugzilla.kernel.org/show_bug.cgi?id=170741 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853122 Best regards, Zoltán

Geode LX AES driver warning, kernel 4.9.10

Hi, this did not occur in the 4.8.x series but I get this with 4.9.9 and 4.9.10: [ 13.785289] [ cut here ] [ 13.785314] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:344 driver_probe_device+0x3f7/0x430 [ 13.785319] Modules linked in: [ 13.785339] CPU: 0 PID: 1

Geode LX AES driver warning, kernel 4.9.10

Hi, this did not occur in the 4.8.x series but I get this with 4.9.9 and 4.9.10: [ 13.785289] [ cut here ] [ 13.785314] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:344 driver_probe_device+0x3f7/0x430 [ 13.785319] Modules linked in: [ 13.785339] CPU: 0 PID: 1

Graphics console with VESAFB doesn't kick in in kernel 4.4.x

Hi, I have tried kernel 4.4.0, 4.4.3 and 4.4.4 on an old Geode LX based POS computer where the usual way to use graphics is VESAFB and optionally Xorg with the VESA driver. With vga=0x314 with or without video=vesafb:mtrr:3 the graphics mode is set but VESAFB doesn't start. There is no /dev/fb0

Graphics console with VESAFB doesn't kick in in kernel 4.4.x

Hi, I have tried kernel 4.4.0, 4.4.3 and 4.4.4 on an old Geode LX based POS computer where the usual way to use graphics is VESAFB and optionally Xorg with the VESA driver. With vga=0x314 with or without video=vesafb:mtrr:3 the graphics mode is set but VESAFB doesn't start. There is no /dev/fb0

Re: [PATCH v2] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-12-04 09:53 keltezéssel, Christian König írta: > On 04.12.2015 00:26, cp...@redhat.com wrote: >> From: Lyude >> >> HPD signals on DVI ports can be fired off before the pins required for >> DDC probing actually make contact, due to the pins for HPD making >> contact first. This results in a

Re: [PATCH v2] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-12-04 09:53 keltezéssel, Christian König írta: > On 04.12.2015 00:26, cp...@redhat.com wrote: >> From: Lyude >> >> HPD signals on DVI ports can be fired off before the pins required for >> DDC probing actually make contact, due to the pins for HPD making >> contact first.

Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-11-20 16:52 keltezéssel, cp...@redhat.com írta: > From: Stephen Chandler Paul > > HPD signals on DVI ports can be fired off before the pins required for > DDC probing actually make contact, due to the pins for HPD making > contact first. This results in a HPD signal being asserted but DDC >

Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-11-20 16:52 keltezéssel, cp...@redhat.com írta: > From: Stephen Chandler Paul > > HPD signals on DVI ports can be fired off before the pins required for > DDC probing actually make contact, due to the pins for HPD making > contact first. This results in a HPD signal being

Re: [Bugfix v3] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32-bit kernel

2015-06-24 12:18 keltezéssel, Ingo Molnar írta: > * Jiang Liu wrote: > >> A regression report from Boszormenyi Zoltan : >> There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID >> 1565:230e) >> network chip on the mainboard. After the r8169 driver load

Re: [Bugfix v3] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32-bit kernel

2015-06-24 12:18 keltezéssel, Ingo Molnar írta: * Jiang Liu jiang@linux.intel.com wrote: A regression report from Boszormenyi Zoltan zbos...@pr.hu: There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID 1565:230e) network chip on the mainboard. After the r8169 driver loaded

Re: [Bugfix v2] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

2015-06-24 10:25 keltezéssel, Boszormenyi Zoltan írta: > 2015-06-24 09:43 keltezéssel, Jiang Liu írta: >> Hi Zoltan, >> Could you please help to test this patch against the latest kernel? >> Thanks! >> Gerry > I will, thanks. Now i have tested this v2. I assu

Re: [Bugfix v2] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

2015-06-24 10:30 keltezéssel, Ingo Molnar írta: > * Jiang Liu wrote: > >> Since commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource >> interfaces to >> simplify implementation"), x86 PCI ACPI host bridge driver validates ACPI >> resources by first converting an ACPI resource to a

Re: [Bugfix v2] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

urce descriptor with address range [0x4-0xf]. > Please refer to https://lkml.org/lkml/2015/6/19/277 for more information. > > Reported-by: Boszormenyi Zoltan > Fixes: 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces to > simplify implement

Re: [Bugfix v2] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

2015-06-24 10:30 keltezéssel, Ingo Molnar írta: * Jiang Liu jiang@linux.intel.com wrote: Since commit 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation), x86 PCI ACPI host bridge driver validates ACPI resources by first converting an ACPI

Re: [Bugfix v2] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

://lkml.org/lkml/2015/6/19/277 for more information. Reported-by: Boszormenyi Zoltan zbos...@pr.hu Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation) Signed-off-by: Jiang Liu jiang@linux.intel.com Cc: sta...@vger.kernel.org # 4.0 --- Hi Zoltan

Re: [Bugfix v2] PCI, ACPI: Fix regressions caused by resource_size_t overflow with 32bit kernel

2015-06-24 10:25 keltezéssel, Boszormenyi Zoltan írta: 2015-06-24 09:43 keltezéssel, Jiang Liu írta: Hi Zoltan, Could you please help to test this patch against the latest kernel? Thanks! Gerry I will, thanks. Now i have tested this v2. I assume later ones will only differ

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 20:55 keltezéssel, Boszormenyi Zoltan írta: > 2015-06-21 19:55 keltezéssel, Jiang Liu írta: >> On 2015/6/22 1:25, Jiang Liu wrote: >> [...] >>>>>> - Memory behind bridge: 8000-801f >>>>>> - Prefetchable memory behin

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 19:55 keltezéssel, Jiang Liu írta: > On 2015/6/22 1:25, Jiang Liu wrote: > [...] > - Memory behind bridge: 8000-801f > - Prefetchable memory behind bridge: > 8020-803f > + Memory behind bridge: ff00-ff1f > +

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 19:25 keltezéssel, Jiang Liu írta: > On 2015/6/21 22:19, Boszormenyi Zoltan wrote: >> 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: >>> [+cc linux-pci] >>> >>> Hi Boszormenyi, >>> >>> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 16:19 keltezéssel, Boszormenyi Zoltan írta: > 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: >> [+cc linux-pci] >> >> Hi Boszormenyi, >> >> On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan wrote: >>> Hi, >>> >>

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: > [+cc linux-pci] > > Hi Boszormenyi, > > On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan wrote: >> Hi, >> >> please, cc me, I am not subscribed to lkml. >> >>> Hi, >>> >>>

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

Hi, please, cc me, I am not subscribed to lkml. > Hi, > > [lkml.org still broken --> no accurate mail header info possible...] > > Just to ask the obvious: > I assume using /sys/bus/pci/rescan does not help once it's broken? > (since the machine comes up empty at initial-boot scan, too) I will

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: [+cc linux-pci] Hi Boszormenyi, On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan zbos...@pr.hu wrote: Hi, please, cc me, I am not subscribed to lkml. Hi, [lkml.org still broken -- no accurate mail header info possible...] Just

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 16:19 keltezéssel, Boszormenyi Zoltan írta: 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: [+cc linux-pci] Hi Boszormenyi, On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan zbos...@pr.hu wrote: Hi, please, cc me, I am not subscribed to lkml. Hi, [lkml.org still broken

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

Hi, please, cc me, I am not subscribed to lkml. Hi, [lkml.org still broken -- no accurate mail header info possible...] Just to ask the obvious: I assume using /sys/bus/pci/rescan does not help once it's broken? (since the machine comes up empty at initial-boot scan, too) I will try it,

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 20:55 keltezéssel, Boszormenyi Zoltan írta: 2015-06-21 19:55 keltezéssel, Jiang Liu írta: On 2015/6/22 1:25, Jiang Liu wrote: [...] - Memory behind bridge: 8000-801f - Prefetchable memory behind bridge: 8020-803f + Memory behind

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 19:25 keltezéssel, Jiang Liu írta: On 2015/6/21 22:19, Boszormenyi Zoltan wrote: 2015-06-21 16:03 keltezéssel, Bjorn Helgaas írta: [+cc linux-pci] Hi Boszormenyi, On Sun, Jun 21, 2015 at 5:34 AM, Boszormenyi Zoltan zbos...@pr.hu wrote: Hi, please, cc me, I am not subscribed

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-21 19:55 keltezéssel, Jiang Liu írta: On 2015/6/22 1:25, Jiang Liu wrote: [...] - Memory behind bridge: 8000-801f - Prefetchable memory behind bridge: 8020-803f + Memory behind bridge: ff00-ff1f + Prefetchable memory

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-20 01:13 keltezéssel, Rafael J. Wysocki írta: > On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote: >> Hi, >> >> so after the network card came alive again, I tried kernels >> 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when >> loadi

Re: ACPI regression? Was Re: Ethernet chip disappeared from lspci

2015-06-20 01:13 keltezéssel, Rafael J. Wysocki írta: On Friday, June 19, 2015 03:46:48 PM Boszormenyi Zoltan wrote: Hi, so after the network card came alive again, I tried kernels 3.18.16, 4.0.5 and 4.1.0-rc8. With the last two kernels, when loading the r8169 driver, I experience

ACPI regression? Was Re: Ethernet chip disappeared from lspci

with r8169. Best regards, Zoltán Böszörményi 2015-06-19 15:31 keltezéssel, Boszormenyi Zoltan írta: > Nevermind, this is a POS machine with a big battery inside. > When I allowed it to discharge, the network card came back > with PXE boot. There might have been some bad state kept > by

Ethernet chip disappeared from lspci

Hi, I have a problem on a special POS mainboard that has a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5. The initial problem was that when r8169 was not blacklisted, as soon as this driver loaded, a lot of IRQ problems popped up, like pressing keys on the USB keyboard made the

Re: Ethernet chip disappeared from lspci

Nevermind, this is a POS machine with a big battery inside. When I allowed it to discharge, the network card came back with PXE boot. There might have been some bad state kept by the battery. Sorry for the noise. 2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta: > Hi, > > I have

Ethernet chip disappeared from lspci

Hi, I have a problem on a special POS mainboard that has a Realtek RTL8111/8168/8411 chip. I use mainline kernel 4.0.5. The initial problem was that when r8169 was not blacklisted, as soon as this driver loaded, a lot of IRQ problems popped up, like pressing keys on the USB keyboard made the

ACPI regression? Was Re: Ethernet chip disappeared from lspci

with r8169. Best regards, Zoltán Böszörményi 2015-06-19 15:31 keltezéssel, Boszormenyi Zoltan írta: Nevermind, this is a POS machine with a big battery inside. When I allowed it to discharge, the network card came back with PXE boot. There might have been some bad state kept by the battery. Sorry

Re: Ethernet chip disappeared from lspci

Nevermind, this is a POS machine with a big battery inside. When I allowed it to discharge, the network card came back with PXE boot. There might have been some bad state kept by the battery. Sorry for the noise. 2015-06-19 15:24 keltezéssel, Boszormenyi Zoltan írta: Hi, I have a problem

Re: New prototype computer problem with S3 suspend

2013-06-07 03:17 keltezéssel, Aaron Lu írta: On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote: Hi, we are working on an Intel Atom-based embedded PC and I have to make suspend-to-RAM work but I can't seem to succeed. The symptom is that quite often, the machine resumes immediately after pm

Re: New prototype computer problem with S3 suspend

2013-06-07 03:17 keltezéssel, Aaron Lu írta: On 06/07/2013 02:11 AM, Boszormenyi Zoltan wrote: Hi, we are working on an Intel Atom-based embedded PC and I have to make suspend-to-RAM work but I can't seem to succeed. The symptom is that quite often, the machine resumes immediately after pm

Re: ahci driver cannot suspend a CF card, ata_piix can

Hi, 2013-04-19 17:14 keltezéssel, Aaron Lu írta: On 04/16/2013 07:58 PM, Boszormenyi Zoltan wrote: Hi, The SATA interface can be switched between AHCI and legacy modes as usual: 00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02) The device

Re: ahci driver cannot suspend a CF card, ata_piix can

Hi, 2013-04-19 17:14 keltezéssel, Aaron Lu írta: On 04/16/2013 07:58 PM, Boszormenyi Zoltan wrote: Hi, The SATA interface can be switched between AHCI and legacy modes as usual: 00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02) The device

Re: ahci driver cannot suspend a CF card, ata_piix can

Hi, 2013-04-19 17:14 keltezéssel, Aaron Lu írta: On 04/16/2013 07:58 PM, Boszormenyi Zoltan wrote: Hi, The SATA interface can be switched between AHCI and legacy modes as usual: 00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02) The device

Re: ahci driver cannot suspend a CF card, ata_piix can

Hi, 2013-04-19 17:14 keltezéssel, Aaron Lu írta: On 04/16/2013 07:58 PM, Boszormenyi Zoltan wrote: Hi, The SATA interface can be switched between AHCI and legacy modes as usual: 00:1f.2 SATA controller: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] (rev 02) The device

ahci driver cannot suspend a CF card, ata_piix can

Hi, I am working with an embedded system, using the Intel Atom CPU, and the usual motherboard components: # lspci 00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Atom Processor

ahci driver cannot suspend a CF card, ata_piix can

Hi, I am working with an embedded system, using the Intel Atom CPU, and the usual motherboard components: # lspci 00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Atom Processor

Re: loadavg question

that mentioned here? http://comments.gmane.org/gmane.linux.kernel/1346108 Respectfully Azat Khuzhin. >From phone. On Feb 28, 2013 4:40 PM, "Boszormenyi Zoltan" mailto:zbos...@pr.hu>> wrote: Hi, on an embedded PC (500MHz AMD Geode), we recently tried to upgrade the kernel. T

loadavg question

Hi, on an embedded PC (500MHz AMD Geode), we recently tried to upgrade the kernel. The original version was 2.6.27, the new ones were 3.3.x and 3.7.x. With the same userspace (a GTK based GUI constantly querying daemons handling different pieces of hardware over serial ports), we noticed that

loadavg question

Hi, on an embedded PC (500MHz AMD Geode), we recently tried to upgrade the kernel. The original version was 2.6.27, the new ones were 3.3.x and 3.7.x. With the same userspace (a GTK based GUI constantly querying daemons handling different pieces of hardware over serial ports), we noticed that

Re: loadavg question

that mentioned here? http://comments.gmane.org/gmane.linux.kernel/1346108 Respectfully Azat Khuzhin. From phone. On Feb 28, 2013 4:40 PM, Boszormenyi Zoltan zbos...@pr.hu mailto:zbos...@pr.hu wrote: Hi, on an embedded PC (500MHz AMD Geode), we recently tried to upgrade the kernel

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

2013-01-04 08:40 keltezéssel, Borislav Petkov írta: On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote: From: Alex Deucher Date: Wed, 2 Jan 2013 18:30:21 -0500 Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers count must be a multiple of 2. Cc: Borislav Petkov

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

2013-01-04 08:40 keltezéssel, Borislav Petkov írta: On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote: From: Alex Deucher alexander.deuc...@amd.com Date: Wed, 2 Jan 2013 18:30:21 -0500 Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers count must be a multiple of

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

2013-01-03 00:37 keltezéssel, Alex Deucher írta: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch :

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

2013-01-03 00:37 keltezéssel, Alex Deucher írta: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch :

Re: Drop support for x86-32

Dear wbrana, this would have been the perfect April 1st joke along the lines of removing support for *all* CPU architectures and adding support for the one true virtual CPU, the Turing machine. Now you spoiled it, shame on you! :-D Best regards, Zoltán Böszörményi -- To unsubscribe from this

Re: Drop support for x86-32

Dear wbrana, this would have been the perfect April 1st joke along the lines of removing support for *all* CPU architectures and adding support for the one true virtual CPU, the Turing machine. Now you spoiled it, shame on you! :-D Best regards, Zoltán Böszörményi -- To unsubscribe from this

Re: [patch] softirq-2.4.6-C3

Hi! I tried this and do_softirq is still unresolved symbol if CONFIG_MODVERSIONS is set to y. Works ok if not. linux-2.4.6-pre1 + softirq-2.4.6-B4 + softirq-2.4.6-C3. Regards, Zoltan Boszormenyi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [patch] softirq-2.4.6-C3

Hi! I tried this and do_softirq is still unresolved symbol if CONFIG_MODVERSIONS is set to y. Works ok if not. linux-2.4.6-pre1 + softirq-2.4.6-B4 + softirq-2.4.6-C3. Regards, Zoltan Boszormenyi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

tcdrain() problem?

Hi! I use the serial line for communication with a device. The communication looks like this: 1. ask the device about its state (a 4 byte packet) 2. read reply from device 3. decide what to do: 3a. if nothing to do, go to 1. 3b. if there is something to do, send the answer to the device

tcdrain() problem?

Hi! I use the serial line for communication with a device. The communication looks like this: 1. ask the device about its state (a 4 byte packet) 2. read reply from device 3. decide what to do: 3a. if nothing to do, go to 1. 3b. if there is something to do, send the answer to the device

Re: Linux not adhering to BIOS Drive boot order?

On Wed, 17 Jan 2001, David Balazic wrote: > BTW, where is the scsihosts= kernel parameter documented ? linux/Documentation/filesystems/devfs/README Regards, Zoltan Boszormenyi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

2.4.0-vmpatch-15.1 still no go

On Tue, 9 Jan 2001, Boszormenyi Zoltan wrote: > Hi! > > PF_RSSTRIM is not declared anywhere either in the linux-2.4.0 sources > or in the 2.4.0-vmbigpatch. [zozo@localhost kernel]$ tar xIf linux-2.4.0.tar.bz2 [zozo@localhost kernel]$ cd linux [zozo@localhost linux]$ cat ../patches

2.4.0-vmpatch-15.1 still no go

On Tue, 9 Jan 2001, Boszormenyi Zoltan wrote: Hi! PF_RSSTRIM is not declared anywhere either in the linux-2.4.0 sources or in the 2.4.0-vmbigpatch. [zozo@localhost kernel]$ tar xIf linux-2.4.0.tar.bz2 [zozo@localhost kernel]$ cd linux [zozo@localhost linux]$ cat ../patches/2.4.0/2.4.0

Re: Linux not adhering to BIOS Drive boot order?

On Wed, 17 Jan 2001, David Balazic wrote: BTW, where is the scsihosts= kernel parameter documented ? linux/Documentation/filesystems/devfs/README Regards, Zoltan Boszormenyi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]

  1   2   >