Re: [PATCH 5.9 24/74] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

[Hans-Peter Jansen]

Am Dienstag, 3. November 2020, 07:35:29 CET schrieb Greg Kroah-Hartman:
> On Mon, Nov 02, 2020 at 10:34:08PM +0100, Hans-Peter Jansen wrote:
> 
> Ah, that kind of makes sense, I saw odd things with these patches that I
> couldn't figure out.
> 
> So, is there a symlink that I need to add/fix to resolve this?

rm tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S should 
do the trick.

Cheers,
Pete

Re: [PATCH 5.9 24/74] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

[Hans-Peter Jansen]

Hi Greg, hi Dan,

Am Samstag, 31. Oktober 2020, 12:36:06 CET schrieb Greg Kroah-Hartman:
> From: Dan Williams 
> 
> commit ec6347bb43395cb92126788a1a5b25302543f815 upstream.
> 
> In reaction to a proposal to introduce a memcpy_mcsafe_fast()
> implementation Linus points out that memcpy_mcsafe() is poorly named
> relative to communicating the scope of the interface. Specifically what
> addresses are valid to pass as source, destination, and what faults /
> exceptions are handled.
> 
> 
> Introduce an x86 copy_mc_fragile() name as the rename for the
> low-level x86 implementation formerly named memcpy_mcsafe(). It is used
> as the slow / careful backend that is supplanted by a fast
> copy_mc_generic() in a follow-on patch.
> 
> One side-effect of this reorganization is that separating copy_mc_64.S
> to its own file means that perf no longer needs to track dependencies
> for its memcpy_64.S benchmarks.
> 
> ---
> arch/powerpc/lib/copy_mc_64.S  |  242 
> +
> arch/powerpc/lib/memcpy_mcsafe_64.S|  242 
> -

> tools/testing/selftests/powerpc/copyloops/copy_mc_64.S |  242 
> + 

This change leaves a dangling symlink in 
tools/testing/selftests/powerpc/copyloops behind. At least, this is, what I 
could track down, when building 5.9.3 within an environment, that bails out 
on this:

[ 2908s] calling /usr/lib/rpm/brp-suse.d/brp-25-symlink
[ 2908s] ERROR: link target doesn't exist (neither in build root nor in 
installed system):
[ 2908s]   
/usr/src/linux-5.9.3-lp152.3-vanilla/tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S
 -> /usr/src/linux-5.9.3-lp152.3-vanilla/arch/powerpc/lib/memcpy_mcsafe_64.S
[ 2908s] Add the package providing the target to BuildRequires and Requires
[ 2909s] INFO: relinking 
/usr/src/linux-5.9.3-lp152.3-vanilla/tools/testing/selftests/powerpc/primitives/asm/asm-compat.h
 -> ../../../../../../arch/powerpc/include/asm/asm-compat.h (was 
../.././../../../../arch/powerpc/include/asm/asm-compat.h)

Linus` tree seems to not suffer from this, though.

Cheers,
Pete

Re: AMD PCI Bridge: Hardware error from APEI

[Hans-Peter Jansen]

Am Samstag, 11. Juli 2020, 18:32:21 CEST schrieben Sie:
> Am Dienstag, 7. Juli 2020, 08:56:41 CEST schrieben Sie:
> > Am Samstag, 27. Juni 2020, 20:23:35 CEST schrieben Sie:
> > > Dear hacker from the order of the penguins,
> > > 
> > > we're facing a disturbing issue here after swapping a motherboard of a
> > > mission critical system:
> > > 
> > > Specs:
> > > ASUS KNPA-U16 with an AMD EPYC 7261, 2x32 GB Kingston KSM26RD4/32MEI
> > > (officially supported RAM modules)
> > > 
> > > openSUSE 15.1, Kernel 5.7.5
> > 
> > Not sure, how to proceed with this one?
> > 
> > After 9½ days uptime, it cumulated about 34,000 incidents:
> > 
> > [...]
> > 
> > Needless so say, that this is no permanent solution.
> > 
> > Any ideas anybody?
> 
> After swapping the PCIe slot for the Digital Devices Max S8 4/8, the error
> has moved:
> 
> 2020-07-11T18:25:34.380002+02:00 tyrex kernel: [  889.223783] {20}[Hardware
> Error]: Hardware error from APEI Generic Hardware Error Source: 4
> 2020-07-11T18:25:34.380025+02:00 tyrex kernel: [  889.223787] {20}[Hardware
> Error]: It has been corrected by h/w and requires no further action
> 2020-07-11T18:25:34.380028+02:00 tyrex kernel: [  889.223789] {20}[Hardware
> Error]: event severity: corrected 2020-07-11T18:25:34.380031+02:00 tyrex
> kernel: [  889.223791] {20}[Hardware Error]:  Error 0, type: corrected
> 2020-07-11T18:25:34.380032+02:00 tyrex kernel: [  889.223793] {20}[Hardware
> Error]:  fru_text: PcieError 2020-07-11T18:25:34.380034+02:00 tyrex kernel:
> [  889.223795] {20}[Hardware Error]:   section_type: PCIe error
> 2020-07-11T18:25:34.380577+02:00 tyrex kernel: [  889.223796] {20}[Hardware
> Error]:   port_type: 4, root port 2020-07-11T18:25:34.380586+02:00 tyrex
> kernel: [  889.223798] {20}[Hardware Error]:   version: 0.2
> 2020-07-11T18:25:34.380588+02:00 tyrex kernel: [  889.223800] {20}[Hardware
> Error]:   command: 0x0407, status: 0x0010 2020-07-11T18:25:34.380590+02:00
> tyrex kernel: [  889.223802] {20}[Hardware Error]:   device_id:
> :40:03.1 2020-07-11T18:25:34.380591+02:00 tyrex kernel: [  889.223803]
> {20}[Hardware Error]:   slot: 16 2020-07-11T18:25:34.380593+02:00 tyrex
> kernel: [  889.223804] {20}[Hardware Error]:   secondary_bus: 0x41
> 2020-07-11T18:25:34.380595+02:00 tyrex kernel: [  889.223806] {20}[Hardware
> Error]:   vendor_id: 0x1022, device_id: 0x1453
> 2020-07-11T18:25:34.380597+02:00 tyrex kernel: [  889.223808] {20}[Hardware
> Error]:   class_code: 060400 2020-07-11T18:25:34.380599+02:00 tyrex kernel:
> [  889.223810] {20}[Hardware Error]:   bridge: secondary_status: 0x2000,
> control: 0x0012 2020-07-11T18:25:34.380601+02:00 tyrex kernel: [ 
> 889.223908] pcieport :40:03.1: AER: aer_status: 0x1000, aer_mask:
> 0x6000 2020-07-11T18:25:34.380603+02:00 tyrex kernel: [  889.223912]
> pcieport :40:03.1: AER:[12] Timeout
> 2020-07-11T18:25:34.380605+02:00 tyrex kernel: [  889.223915] pcieport
> :40:03.1: AER: aer_layer=Data Link Layer, aer_agent=Transmitter ID
> 
> It looks like the system is creating such devices on demand:
> 
> 40:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
> 00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode]) Flags: bus master,
> fast devsel, latency 0, IRQ 39, NUMA node 2 Bus: primary=40, secondary=41,
> subordinate=41, sec-latency=0 I/O behind bridge: None
> Memory behind bridge: e5d0-e5df [size=1M]
> Prefetchable memory behind bridge: None
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Root Port (Slot+), MSI 00
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD]
> Family 17h (Models 00h-0fh) PCIe GPP Bridge Capabilities: [c8]
> HyperTransport: MSI Mapping Enable+ Fixed+ Capabilities: [100] Vendor
> Specific Information: ID=0001 Rev=1 Len=010  Capabilities: [150]
> Advanced Error Reporting
> Capabilities: [270] #19
> Capabilities: [2a0] Access Control Services
> Capabilities: [370] L1 PM Substates
> Capabilities: [380] Downstream Port Containment
> Capabilities: [3c4] #23
> Kernel driver in use: pcieport
> 
> in order to handle:
> 
> 41:00.0 Multimedia controller: Digital Devices GmbH Max
> Subsystem: Digital Devices GmbH Max S8 4/8
> Flags: bus master, fast devsel, latency 0, IRQ 181, NUMA node 2
> Memory at e5d0 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [50] Power Management version 3
> Capabilities: [70] MSI: Enable- Count=1/2 Maskable- 64bit+
> Capabilities: [90] Express Endpoint, MSI 00
> Capabilities: [100] Vendor Specific Information: ID= Rev=0
> Len=00c  Kernel driver in use: ddbridge
> Kernel modules: ddbridge

Here's the initialization sequence of these devices:

Jul 13 12:19:27 tyrex kernel: pci :40:03.1: [1022:1453] type 01 class 
0x060400
Jul 13 12:19:27 tyrex 

Re: AMD PCI Bridge: Hardware error from APEI

[Hans-Peter Jansen]

Am Dienstag, 7. Juli 2020, 08:56:41 CEST schrieben Sie:
> Am Samstag, 27. Juni 2020, 20:23:35 CEST schrieben Sie:
> > Dear hacker from the order of the penguins,
> > 
> > we're facing a disturbing issue here after swapping a motherboard of a
> > mission critical system:
> > 
> > Specs:
> > ASUS KNPA-U16 with an AMD EPYC 7261, 2x32 GB Kingston KSM26RD4/32MEI
> > (officially supported RAM modules)
> > 
> > openSUSE 15.1, Kernel 5.7.5
> 
> Not sure, how to proceed with this one?
> 
> After 9½ days uptime, it cumulated about 34,000 incidents:
>
> [...]
> 
> Needless so say, that this is no permanent solution.
> 
> Any ideas anybody?

After swapping the PCIe slot for the Digital Devices Max S8 4/8, the error has 
moved: 

2020-07-11T18:25:34.380002+02:00 tyrex kernel: [  889.223783] {20}[Hardware 
Error]: Hardware error from APEI Generic Hardware Error Source: 4
2020-07-11T18:25:34.380025+02:00 tyrex kernel: [  889.223787] {20}[Hardware 
Error]: It has been corrected by h/w and requires no further action
2020-07-11T18:25:34.380028+02:00 tyrex kernel: [  889.223789] {20}[Hardware 
Error]: event severity: corrected
2020-07-11T18:25:34.380031+02:00 tyrex kernel: [  889.223791] {20}[Hardware 
Error]:  Error 0, type: corrected
2020-07-11T18:25:34.380032+02:00 tyrex kernel: [  889.223793] {20}[Hardware 
Error]:  fru_text: PcieError
2020-07-11T18:25:34.380034+02:00 tyrex kernel: [  889.223795] {20}[Hardware 
Error]:   section_type: PCIe error
2020-07-11T18:25:34.380577+02:00 tyrex kernel: [  889.223796] {20}[Hardware 
Error]:   port_type: 4, root port
2020-07-11T18:25:34.380586+02:00 tyrex kernel: [  889.223798] {20}[Hardware 
Error]:   version: 0.2
2020-07-11T18:25:34.380588+02:00 tyrex kernel: [  889.223800] {20}[Hardware 
Error]:   command: 0x0407, status: 0x0010
2020-07-11T18:25:34.380590+02:00 tyrex kernel: [  889.223802] {20}[Hardware 
Error]:   device_id: :40:03.1
2020-07-11T18:25:34.380591+02:00 tyrex kernel: [  889.223803] {20}[Hardware 
Error]:   slot: 16
2020-07-11T18:25:34.380593+02:00 tyrex kernel: [  889.223804] {20}[Hardware 
Error]:   secondary_bus: 0x41
2020-07-11T18:25:34.380595+02:00 tyrex kernel: [  889.223806] {20}[Hardware 
Error]:   vendor_id: 0x1022, device_id: 0x1453
2020-07-11T18:25:34.380597+02:00 tyrex kernel: [  889.223808] {20}[Hardware 
Error]:   class_code: 060400
2020-07-11T18:25:34.380599+02:00 tyrex kernel: [  889.223810] {20}[Hardware 
Error]:   bridge: secondary_status: 0x2000, control: 0x0012
2020-07-11T18:25:34.380601+02:00 tyrex kernel: [  889.223908] pcieport 
:40:03.1: AER: aer_status: 0x1000, aer_mask: 0x6000
2020-07-11T18:25:34.380603+02:00 tyrex kernel: [  889.223912] pcieport 
:40:03.1: AER:[12] Timeout   
2020-07-11T18:25:34.380605+02:00 tyrex kernel: [  889.223915] pcieport 
:40:03.1: AER: aer_layer=Data Link Layer, aer_agent=Transmitter ID

It looks like the system is creating such devices on demand:

40:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 39, NUMA node 2
Bus: primary=40, secondary=41, subordinate=41, sec-latency=0
I/O behind bridge: None
Memory behind bridge: e5d0-e5df [size=1M]
Prefetchable memory behind bridge: None
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Port (Slot+), MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Family 
17h (Models 00h-0fh) PCIe GPP Bridge
Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 

Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Capabilities: [2a0] Access Control Services
Capabilities: [370] L1 PM Substates
Capabilities: [380] Downstream Port Containment
Capabilities: [3c4] #23
Kernel driver in use: pcieport

in order to handle:

41:00.0 Multimedia controller: Digital Devices GmbH Max
Subsystem: Digital Devices GmbH Max S8 4/8
Flags: bus master, fast devsel, latency 0, IRQ 181, NUMA node 2
Memory at e5d0 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable- Count=1/2 Maskable- 64bit+
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=00c 

Kernel driver in use: ddbridge
Kernel modules: ddbridge

Hrmpf.

Pete

Re: AMD PCI Bridge: Hardware error from APEI

[Hans-Peter Jansen]

Am Samstag, 27. Juni 2020, 20:23:35 CEST schrieben Sie:
> Dear hacker from the order of the penguins,
> 
> we're facing a disturbing issue here after swapping a motherboard of a
> mission critical system:
> 
> Jun 27 20:05:29 server kernel: {10}[Hardware Error]: Hardware error from
> APEI Generic Hardware Error Source: 4 Jun 27 20:05:29 server kernel:
> {10}[Hardware Error]: It has been corrected by h/w and requires no further
> action Jun 27 20:05:29 server kernel: {10}[Hardware Error]: event severity:
> corrected Jun 27 20:05:29 server kernel: {10}[Hardware Error]:  Error 0,
> type: corrected Jun 27 20:05:29 server kernel: {10}[Hardware Error]: 
> fru_text: PcieError Jun 27 20:05:29 server kernel: {10}[Hardware Error]:  
> section_type: PCIe error Jun 27 20:05:29 server kernel: {10}[Hardware
> Error]:   port_type: 4, root port Jun 27 20:05:29 server kernel:
> {10}[Hardware Error]:   version: 0.2 Jun 27 20:05:29 server kernel:
> {10}[Hardware Error]:   command: 0x0407, status: 0x0010 Jun 27 20:05:29
> server kernel: {10}[Hardware Error]:   device_id: :60:03.1 Jun 27
> 20:05:29 server kernel: {10}[Hardware Error]:   slot: 19
> Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   secondary_bus: 0x62
> Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   vendor_id: 0x1022,
> device_id: 0x1453 Jun 27 20:05:29 server kernel: {10}[Hardware Error]:  
> class_code: 060400 Jun 27 20:05:29 server kernel: {10}[Hardware Error]:  
> bridge: secondary_status: 0x2000, control: 0x0012 Jun 27 20:05:29 server
> kernel: pcieport :60:03.1: AER: aer_status: 0x1000, aer_mask:
> 0x6000 Jun 27 20:05:29 server kernel: pcieport :60:03.1: AER:   
> [12] Timeout Jun 27 20:05:29 server kernel: pcieport :60:03.1: AER:
> aer_layer=Data Link Layer, aer_agent=Transmitter ID
> 
> 
> Jun 27 20:05:51 server kernel: {11}[Hardware Error]: Hardware error from
> APEI Generic Hardware Error Source: 4 Jun 27 20:05:51 server kernel:
> {11}[Hardware Error]: It has been corrected by h/w and requires no further
> action Jun 27 20:05:51 server kernel: {11}[Hardware Error]: event severity:
> corrected Jun 27 20:05:51 server kernel: {11}[Hardware Error]:  Error 0,
> type: corrected Jun 27 20:05:51 server kernel: {11}[Hardware Error]: 
> fru_text: PcieError Jun 27 20:05:51 server kernel: {11}[Hardware Error]:  
> section_type: PCIe error Jun 27 20:05:51 server kernel: {11}[Hardware
> Error]:   port_type: 4, root port Jun 27 20:05:51 server kernel:
> {11}[Hardware Error]:   version: 0.2 Jun 27 20:05:51 server kernel:
> {11}[Hardware Error]:   command: 0x0407, status: 0x0010 Jun 27 20:05:51
> server kernel: {11}[Hardware Error]:   device_id: :60:03.1 Jun 27
> 20:05:51 server kernel: {11}[Hardware Error]:   slot: 19
> Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   secondary_bus: 0x62
> Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   vendor_id: 0x1022,
> device_id: 0x1453 Jun 27 20:05:51 server kernel: {11}[Hardware Error]:  
> class_code: 060400 Jun 27 20:05:51 server kernel: {11}[Hardware Error]:  
> bridge: secondary_status: 0x2000, control: 0x0012 Jun 27 20:05:51 server
> kernel: pcieport :60:03.1: AER: aer_status: 0x1000, aer_mask:
> 0x6000 Jun 27 20:05:51 server kernel: pcieport :60:03.1: AER:   
> [12] Timeout Jun 27 20:05:51 server kernel: pcieport :60:03.1: AER:
> aer_layer=Data Link Layer, aer_agent=Transmitter ID
> 
> 
> 60:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models
> 00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode]) Flags: bus master,
> fast devsel, latency 0, IRQ 44, NUMA node 3 Bus: primary=60, secondary=62,
> subordinate=62, sec-latency=0 I/O behind bridge: None
> Memory behind bridge: e360-e36f [size=1M]
> Prefetchable memory behind bridge: None
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Root Port (Slot+), MSI 00
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD]
> Family 17h (Models 00h-0fh) PCIe GPP Bridge Capabilities: [c8]
> HyperTransport: MSI Mapping Enable+ Fixed+ Capabilities: [100] Vendor
> Specific Information: ID=0001 Rev=1 Len=010  Capabilities: [150]
> Advanced Error Reporting
> Capabilities: [270] #19
> Capabilities: [2a0] Access Control Services
> Capabilities: [370] L1 PM Substates
> Capabilities: [380] Downstream Port Containment
> Capabilities: [3c4] #23
> Kernel driver in use: pcieport
> 
> It's probably related to a satellite receiver card, since it only appeared
> after plugging:
> 
> 62:00.0 Multimedia controller: Digital Devices GmbH Max
> Subsystem: Digital Devices GmbH Max S8 4/8
> Flags: bus master, fast devsel, latency 0, IRQ 161, NUMA node 3
> Memory at e360 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [50] Power Management version 3
> Capabilities: [70] 

AMD PCI Bridge: Hardware error from APEI

[Hans-Peter Jansen]

Dear hacker from the order of the penguins,

we're facing a disturbing issue here after swapping a motherboard of a 
mission critical system:

Jun 27 20:05:29 server kernel: {10}[Hardware Error]: Hardware error from APEI 
Generic Hardware Error Source: 4
Jun 27 20:05:29 server kernel: {10}[Hardware Error]: It has been corrected by 
h/w and requires no further action
Jun 27 20:05:29 server kernel: {10}[Hardware Error]: event severity: corrected
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:  Error 0, type: corrected
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:  fru_text: PcieError
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   section_type: PCIe error
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   port_type: 4, root port
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   version: 0.2
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   command: 0x0407, status: 
0x0010
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   device_id: :60:03.1
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   slot: 19
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   secondary_bus: 0x62
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   vendor_id: 0x1022, 
device_id: 0x1453
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   class_code: 060400
Jun 27 20:05:29 server kernel: {10}[Hardware Error]:   bridge: 
secondary_status: 0x2000, control: 0x0012
Jun 27 20:05:29 server kernel: pcieport :60:03.1: AER: aer_status: 
0x1000, aer_mask: 0x6000
Jun 27 20:05:29 server kernel: pcieport :60:03.1: AER:[12] Timeout  
 
Jun 27 20:05:29 server kernel: pcieport :60:03.1: AER: aer_layer=Data Link 
Layer, aer_agent=Transmitter ID


Jun 27 20:05:51 server kernel: {11}[Hardware Error]: Hardware error from APEI 
Generic Hardware Error Source: 4
Jun 27 20:05:51 server kernel: {11}[Hardware Error]: It has been corrected by 
h/w and requires no further action
Jun 27 20:05:51 server kernel: {11}[Hardware Error]: event severity: corrected
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:  Error 0, type: corrected
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:  fru_text: PcieError
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   section_type: PCIe error
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   port_type: 4, root port
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   version: 0.2
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   command: 0x0407, status: 
0x0010
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   device_id: :60:03.1
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   slot: 19
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   secondary_bus: 0x62
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   vendor_id: 0x1022, 
device_id: 0x1453
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   class_code: 060400
Jun 27 20:05:51 server kernel: {11}[Hardware Error]:   bridge: 
secondary_status: 0x2000, control: 0x0012
Jun 27 20:05:51 server kernel: pcieport :60:03.1: AER: aer_status: 
0x1000, aer_mask: 0x6000
Jun 27 20:05:51 server kernel: pcieport :60:03.1: AER:[12] Timeout  
 
Jun 27 20:05:51 server kernel: pcieport :60:03.1: AER: aer_layer=Data Link 
Layer, aer_agent=Transmitter ID


60:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 44, NUMA node 3
Bus: primary=60, secondary=62, subordinate=62, sec-latency=0
I/O behind bridge: None
Memory behind bridge: e360-e36f [size=1M]
Prefetchable memory behind bridge: None
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Port (Slot+), MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Family 
17h (Models 00h-0fh) PCIe GPP Bridge
Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 

Capabilities: [150] Advanced Error Reporting
Capabilities: [270] #19
Capabilities: [2a0] Access Control Services
Capabilities: [370] L1 PM Substates
Capabilities: [380] Downstream Port Containment
Capabilities: [3c4] #23
Kernel driver in use: pcieport

It's probably related to a satellite receiver card, since it only appeared 
after plugging:

62:00.0 Multimedia controller: Digital Devices GmbH Max
Subsystem: Digital Devices GmbH Max S8 4/8
Flags: bus master, fast devsel, latency 0, IRQ 161, NUMA node 3
Memory at e360 (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable- Count=1/2 Maskable- 64bit+
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [100] 

Re: 4.14.9 broke nvidia 384.98 kernel module

[Hans-Peter Jansen]

On Freitag, 29. Dezember 2017 10:23:56 Greg KH wrote:
> On Fri, Dec 29, 2017 at 02:08:08AM +0100, Hans-Peter Jansen wrote:
> > Hi Greg,
> > 
> > I know, everybody hates NVidia and their proprietary stuff around here.
> > 
> > Anyway, I wanted to let you and followers of 4.14 know, that changes
> > between> 
> > 4.14.8 and 4.14.9 broke both current nvidia kernel drivers. See:
> > 
> > https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compilin
> > g-v384-98-modules-with-linux-v4-14-9-/
> Should be fixed in 4.14.10-rc1, right?

Hmm, building with 4.14.10 without the patch results in:

[   19s] + make -f Makefile nv-linux.o SYSSRC=/lib/modules/4.14.10-3-
default/source SYSOUT=/usr/src/linux-obj/x86_64/default
[...]
[   88s] /home/abuild/rpmbuild/BUILD/nvidia-
gfxG04-384.98/obj/default/384.98/nvidia-uvm/uvm8_va_block.c:8771:41: error: 
implicit declaration of function 'task_stack_page' [-Werror=implicit-function-
declaration]

With the patch applied (attached for reference), the build succeeds..

Cheers,
Petediff -durN nvidia-384-orig/nvidia-uvm/uvm8_va_block.c nvidia-384/nvidia-uvm/uvm8_va_block.c
--- a/kernel/nvidia-uvm/uvm8_va_block.c 2017-12-26 11:20:17.097715622 +0100
+++ b/kernel/nvidia-uvm/uvm8_va_block.c 2017-12-26 11:20:29.674381760 +0100
@@ -36,6 +36,10 @@
 #include "uvm8_perf_prefetch.h"
 #include "uvm8_mem.h"
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,9)
+#include 
+#endif
+
 typedef enum
 {
 BLOCK_PTE_OP_MAP,

Re: 4.14.9 broke nvidia 384.98 kernel module

[Hans-Peter Jansen]

On Freitag, 29. Dezember 2017 10:23:56 Greg KH wrote:
> On Fri, Dec 29, 2017 at 02:08:08AM +0100, Hans-Peter Jansen wrote:
> > Hi Greg,
> > 
> > I know, everybody hates NVidia and their proprietary stuff around here.
> > 
> > Anyway, I wanted to let you and followers of 4.14 know, that changes
> > between> 
> > 4.14.8 and 4.14.9 broke both current nvidia kernel drivers. See:
> > 
> > https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compilin
> > g-v384-98-modules-with-linux-v4-14-9-/
> Should be fixed in 4.14.10-rc1, right?

Hmm, building with 4.14.10 without the patch results in:

[   19s] + make -f Makefile nv-linux.o SYSSRC=/lib/modules/4.14.10-3-
default/source SYSOUT=/usr/src/linux-obj/x86_64/default
[...]
[   88s] /home/abuild/rpmbuild/BUILD/nvidia-
gfxG04-384.98/obj/default/384.98/nvidia-uvm/uvm8_va_block.c:8771:41: error: 
implicit declaration of function 'task_stack_page' [-Werror=implicit-function-
declaration]

With the patch applied (attached for reference), the build succeeds..

Cheers,
Petediff -durN nvidia-384-orig/nvidia-uvm/uvm8_va_block.c nvidia-384/nvidia-uvm/uvm8_va_block.c
--- a/kernel/nvidia-uvm/uvm8_va_block.c 2017-12-26 11:20:17.097715622 +0100
+++ b/kernel/nvidia-uvm/uvm8_va_block.c 2017-12-26 11:20:29.674381760 +0100
@@ -36,6 +36,10 @@
 #include "uvm8_perf_prefetch.h"
 #include "uvm8_mem.h"
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,9)
+#include 
+#endif
+
 typedef enum
 {
 BLOCK_PTE_OP_MAP,

4.14.9 broke nvidia 384.98 kernel module

[Hans-Peter Jansen]

Hi Greg,

I know, everybody hates NVidia and their proprietary stuff around here.

Anyway, I wanted to let you and followers of 4.14 know, that changes between 
4.14.8 and 4.14.9 broke both current nvidia kernel drivers. See:


https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/

Reading though the changelog of 4.14.9, I would call this release courageous 
;-)

Cheers,
Pete

4.14.9 broke nvidia 384.98 kernel module

[Hans-Peter Jansen]

Hi Greg,

I know, everybody hates NVidia and their proprietary stuff around here.

Anyway, I wanted to let you and followers of 4.14 know, that changes between 
4.14.8 and 4.14.9 broke both current nvidia kernel drivers. See:


https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/

Reading though the changelog of 4.14.9, I would call this release courageous 
;-)

Cheers,
Pete

Re: [PATCH 4.2 000/120] 4.2.1-stable review

[Hans-Peter Jansen]

Dear Greg,

FYI, this revision seems to be missing https://lkml.org/lkml/2015/9/3/411

[PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL 
modules

which actually defers 4.2 rollout for some cases, hence for 4.2.1 too.

Cheers,
Pete


On Samstag, 19. September 2015 10:27:20 Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.2.1 release.
> There are 120 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 me know.
> 
> Responses should be made by Mon Sep 21 17:15:44 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.2.1-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman 
> Linux 4.2.1-rc1
> 
> Kees Cook 
> fs: create and use seq_show_option for escaping
> 
> Tang Chen 
> memory-hotplug: add hot-added memory ranges to memblock before allocate
> node_data for a node.
> 
> Ryan Ding 
> ocfs2: direct write will call ocfs2_rw_unlock() twice when doing aio+dio
> 
> Mikulas Patocka 
> hpfs: update ctime and mtime on directory modification
> 
> Eric W. Biederman 
> fs: Set the size of empty dirs to 0.
> 
> Joe Thornber 
> dm cache: fix leaking of deferred bio prison cells
> 
> Mikulas Patocka 
> dm stats: report precise_timestamps and histogram in @stats_list output
> 
> Grant Likely 
> drivercore: Fix unregistration path of platform devices
> 
> Jiang Liu 
> ACPI, PCI: Penalize legacy IRQ used by ACPI SCI
> 
> Heiko Stuebner 
> ARM: dts: rockchip: fix rk3288 watchdog irq
> 
> Caesar Wang 
> ARM: rockchip: fix the CPU soft reset
> 
> Vignesh R 
> ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
> 
> Hyungwon Hwang 
> ARM: dts: fix clock-frequency of display timing0 for exynos3250-rinato
> 
> Benjamin Cama 
> ARM: orion5x: fix legacy orion5x IRQ numbers
> 
> Sudeep Holla 
> ARM: BCM63xx: fix parameter to of_get_cpu_node in
> bcm63138_smp_boot_secondary
> 
> David Daney 
> of/address: Don't loop forever in of_find_matching_node_by_address().
> 
> Thierry Reding 
> soc/tegra: pmc: Avoid usage of uninitialized variable
> 
> Xie XiuQi 
> x86/mce: Reenable CMCI banks when swiching back to interrupt mode
> 
> Kishon Vijay Abraham I 
> regulator: pbias: Fix broken pbias disable functionality
> 
> Sudip Mukherjee 
> auxdisplay: ks0108: fix refcount
> 
> Ricardo Ribalda Delgado 
> spi/spi-xilinx: Fix mixed poll/irq mode
> 
> Ricardo Ribalda Delgado 
> spi/spi-xilinx: Fix spurious IRQ ACK on irq mode
> 
> Peter Chen 
> Doc: ABI: testing: configfs-usb-gadget-sourcesink
> 
> Peter Chen 
> Doc: ABI: testing: configfs-usb-gadget-loopback
> 
> Masahiro Yamada 
> devres: fix devres_get()
> 
> Max Filippov 
> xtensa: fix kernel register spilling
> 
> Max Filippov 
> xtensa: fix threadptr reload on return to userspace
> 
> Paul Mackerras 
> KVM: PPC: Book3S HV: Fix race in reading change bit when removing HPTE
> 
> Gautham R. Shenoy 
> KVM: PPC: Book3S HV: Exit on H_DOORBELL if HOST_IPI is set
> 
> Xiao Guangrong 
> KVM: MMU: fix validation of mmio page fault
> 
> Ellen Wang 
> HID: cp2112: fix I2C_SMBUS_BYTE write
> 
> Ellen Wang 
> HID: cp2112: fix byte order in SMBUS operations
> 
> Don Zickus 
> HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
> 
> Andrey Ryabinin 
> crypto: ghash-clmulni: specify context size for ghash async algorithm
> 
> Leonidas Da Silva Barbosa 
> crypto: vmx - Fixing GHASH Key issue on little endian
> 
> Leonidas Da Silva Barbosa 
> crypto: vmx - Fixing AES-CTR counter bug
> 
> Robert Baldyga 
> serial: samsung: fix DMA for FIFO smaller than cache line size
> 
> Marek Szyprowski 
> serial: samsung: fix DMA mode enter condition for small FIFO sizes
> 
> Adam Lee 
> serial: 8250_pci: Add support for Pericom PI7C9X795[1248]
> 
> Maciej S. Szmigiero 
> serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)
> 
> Maciej S. Szmigiero 
> serial: 8250: don't bind to SMSC IrCC IR port
> 
> Charles Keepax 
> ASoC: arizona: Poll for FLL clock OK rather than use interrupts
> 
> Nikesh Oswal 
> ASoC: arizona: Fix gain settings of FLL in free-run mode
> 
> Axel Lin 
> ASoC: adav80x: Remove .read_flag_mask setting from adav80x_regmap_config
> 
> Vaishali Thakkar 
> ASoC: samsung: Remove redundant arndale_audio_remove
> 
> Oder Chiou 
> ASoC: rt5645: Add struct dmi_system_id "Google Celes" for chrome
> platform
> 
> John Lin 
> ASoC: rt5640: fix line out no sound issue
> 
> Johannes Thumshirn 
> tty: serial: men_z135_uart.c: Fix race between IRQ and set_termios()
> 
> Peter Chen 
> usb: host: ehci-sys: delete useless 

Re: [PATCH 4.2 000/120] 4.2.1-stable review

[Hans-Peter Jansen]

Dear Greg,

FYI, this revision seems to be missing https://lkml.org/lkml/2015/9/3/411

[PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL 
modules

which actually defers 4.2 rollout for some cases, hence for 4.2.1 too.

Cheers,
Pete


On Samstag, 19. September 2015 10:27:20 Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.2.1 release.
> There are 120 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 me know.
> 
> Responses should be made by Mon Sep 21 17:15:44 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.2.1-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman 
> Linux 4.2.1-rc1
> 
> Kees Cook 
> fs: create and use seq_show_option for escaping
> 
> Tang Chen 
> memory-hotplug: add hot-added memory ranges to memblock before allocate
> node_data for a node.
> 
> Ryan Ding 
> ocfs2: direct write will call ocfs2_rw_unlock() twice when doing aio+dio
> 
> Mikulas Patocka 
> hpfs: update ctime and mtime on directory modification
> 
> Eric W. Biederman 
> fs: Set the size of empty dirs to 0.
> 
> Joe Thornber 
> dm cache: fix leaking of deferred bio prison cells
> 
> Mikulas Patocka 
> dm stats: report precise_timestamps and histogram in @stats_list output
> 
> Grant Likely 
> drivercore: Fix unregistration path of platform devices
> 
> Jiang Liu 
> ACPI, PCI: Penalize legacy IRQ used by ACPI SCI
> 
> Heiko Stuebner 
> ARM: dts: rockchip: fix rk3288 watchdog irq
> 
> Caesar Wang 
> ARM: rockchip: fix the CPU soft reset
> 
> Vignesh R 
> ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
> 
> Hyungwon Hwang 
> ARM: dts: fix clock-frequency of display timing0 for exynos3250-rinato
> 
> Benjamin Cama 
> ARM: orion5x: fix legacy orion5x IRQ numbers
> 
> Sudeep Holla 
> ARM: BCM63xx: fix parameter to of_get_cpu_node in
> bcm63138_smp_boot_secondary
> 
> David Daney 
> of/address: Don't loop forever in of_find_matching_node_by_address().
> 
> Thierry Reding 
> soc/tegra: pmc: Avoid usage of uninitialized variable
> 
> Xie XiuQi 
> x86/mce: Reenable CMCI banks when swiching back to interrupt mode
> 
> Kishon Vijay Abraham I 
> regulator: pbias: Fix broken pbias disable functionality
> 
> Sudip Mukherjee 
> auxdisplay: ks0108: fix refcount
> 
> Ricardo Ribalda Delgado 
> spi/spi-xilinx: Fix mixed poll/irq mode
> 
> Ricardo Ribalda Delgado 
> spi/spi-xilinx: Fix spurious IRQ ACK on irq mode
> 
> Peter Chen 
> Doc: ABI: testing: configfs-usb-gadget-sourcesink
> 
> Peter Chen 
> Doc: ABI: testing: configfs-usb-gadget-loopback
> 
> Masahiro Yamada 
> devres: fix devres_get()
> 
> Max Filippov 
> xtensa: fix kernel register spilling
> 
> Max Filippov 
> xtensa: fix threadptr reload on return to userspace
> 
> Paul Mackerras 
> KVM: PPC: Book3S HV: Fix race in reading change bit when removing HPTE
> 
> Gautham R. Shenoy 
> KVM: PPC: Book3S HV: Exit on H_DOORBELL if HOST_IPI is set
> 
> Xiao Guangrong 
> KVM: MMU: fix validation of mmio page fault
> 
> Ellen Wang 
> HID: cp2112: fix I2C_SMBUS_BYTE write
> 
> Ellen Wang 
> HID: cp2112: fix byte order in SMBUS operations
> 
> Don Zickus 
> HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
> 
> Andrey Ryabinin 
> crypto: ghash-clmulni: specify context size for ghash async algorithm
> 
> Leonidas Da Silva Barbosa 
> crypto: vmx - Fixing GHASH Key issue on little endian
> 
> Leonidas Da Silva Barbosa 
> crypto: vmx - Fixing AES-CTR counter bug
> 
> Robert Baldyga 
> serial: samsung: fix DMA for FIFO smaller than cache line size
> 
> Marek Szyprowski 
> serial: samsung: fix DMA mode enter condition for small FIFO sizes
> 
> Adam 

Re: [PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL modules

[Hans-Peter Jansen]

On Dienstag, 4. August 2015 14:05:20 Tejun Heo wrote:
> On Tue, Aug 04, 2015 at 11:26:04AM -0600, tim.gard...@canonical.com wrote:
> > From: Tim Gardner 
> > 
> > Commit 37b1ef31a568fc02e53587620226e5f3c66454c8 ("workqueue: move
> > flush_scheduled_work() to workqueue.h") moved the exported non GPL
> > flush_scheduled_work() from a function to an inline wrapper.
> > Unfortunately, it directly calls flush_workqueue() which is a GPL
> > function.
> > This has the effect of changing the licensing requirement for this
> > function
> > and makes it unavailable to non GPL modules.
> > 
> > See commit ad7b1f841f8a54c6d61ff181451f55b68175e15a ("workqueue: Make
> > schedule_work() available again to non GPL modules") for precedent.
> > 
> > Cc: Tejun Heo 
> > Signed-off-by: Tim Gardner 
> 
> Applied to wq/for-4.3.
> 
> Thanks.

Tejun, mind CCing stable in this regard? 

As things stand right now, it's activily deferring 4.2 rollout for (evil, 
sure) nvidia users like me. 

Thanks,
Pete
--
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 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL modules

[Hans-Peter Jansen]

On Dienstag, 4. August 2015 14:05:20 Tejun Heo wrote:
> On Tue, Aug 04, 2015 at 11:26:04AM -0600, tim.gard...@canonical.com wrote:
> > From: Tim Gardner 
> > 
> > Commit 37b1ef31a568fc02e53587620226e5f3c66454c8 ("workqueue: move
> > flush_scheduled_work() to workqueue.h") moved the exported non GPL
> > flush_scheduled_work() from a function to an inline wrapper.
> > Unfortunately, it directly calls flush_workqueue() which is a GPL
> > function.
> > This has the effect of changing the licensing requirement for this
> > function
> > and makes it unavailable to non GPL modules.
> > 
> > See commit ad7b1f841f8a54c6d61ff181451f55b68175e15a ("workqueue: Make
> > schedule_work() available again to non GPL modules") for precedent.
> > 
> > Cc: Tejun Heo 
> > Signed-off-by: Tim Gardner 
> 
> Applied to wq/for-4.3.
> 
> Thanks.

Tejun, mind CCing stable in this regard? 

As things stand right now, it's activily deferring 4.2 rollout for (evil, 
sure) nvidia users like me. 

Thanks,
Pete
--
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: [GIT PULL] overlay filesystem fixes for 3.18

[Hans-Peter Jansen]

On Freitag, 21. November 2014 13:41:57 Miklos Szeredi wrote:
> On Fri, Nov 21, 2014 at 12:32 PM, Hans-Peter Jansen  wrote:
> > Dear Miklos,
> > 
> > On Donnerstag, 20. November 2014 17:45:31 Miklos Szeredi wrote:
> >> The biggest change is to rename the filesystem from "overlayfs" to
> >> "overlay". This will allow legacy overlayfs to be easily carried by
> >> distros
> >> alongside the new mainline one.
> > 
> > Would you kindly give a firm elaboration of this rename?
> > 
> 
> See this thread:
> 
> https://lkml.org/lkml/2014/11/18/433

Okay, thanks. I  must have missed this one. "overlay" is as good as a name can 
be, IMHO.

Cheers,
Pete
--
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: [GIT PULL] overlay filesystem fixes for 3.18

[Hans-Peter Jansen]

Dear Miklos,

On Donnerstag, 20. November 2014 17:45:31 Miklos Szeredi wrote:
> 
> The biggest change is to rename the filesystem from "overlayfs" to
> "overlay". This will allow legacy overlayfs to be easily carried by distros
> alongside the new mainline one.

Would you kindly give a firm elaboration of this rename? 

Why would a distro kernel maintainer want to keep the external overlayfs 
patches together with the now in kernel module?

Isn't it enough to drop the external patches from distro kernels in order to 
use it successfully or are there any semantic changes hidden that an admin 
should know about?

BTW: congrats to all involved parties. A layered filesystem finally arrived in 
the Linux kernel! This is a quantum leap for creative system architects.

Cheers,
Pete

proud user of aufs (and formerly unionfs) based fat diskless systems since 
about a decade.
--
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: [GIT PULL] overlay filesystem fixes for 3.18

[Hans-Peter Jansen]

Dear Miklos,

On Donnerstag, 20. November 2014 17:45:31 Miklos Szeredi wrote:
 
 The biggest change is to rename the filesystem from overlayfs to
 overlay. This will allow legacy overlayfs to be easily carried by distros
 alongside the new mainline one.

Would you kindly give a firm elaboration of this rename? 

Why would a distro kernel maintainer want to keep the external overlayfs 
patches together with the now in kernel module?

Isn't it enough to drop the external patches from distro kernels in order to 
use it successfully or are there any semantic changes hidden that an admin 
should know about?

BTW: congrats to all involved parties. A layered filesystem finally arrived in 
the Linux kernel! This is a quantum leap for creative system architects.

Cheers,
Pete

proud user of aufs (and formerly unionfs) based fat diskless systems since 
about a decade.
--
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: [GIT PULL] overlay filesystem fixes for 3.18

[Hans-Peter Jansen]

On Freitag, 21. November 2014 13:41:57 Miklos Szeredi wrote:
 On Fri, Nov 21, 2014 at 12:32 PM, Hans-Peter Jansen h...@urpla.net wrote:
  Dear Miklos,
  
  On Donnerstag, 20. November 2014 17:45:31 Miklos Szeredi wrote:
  The biggest change is to rename the filesystem from overlayfs to
  overlay. This will allow legacy overlayfs to be easily carried by
  distros
  alongside the new mainline one.
  
  Would you kindly give a firm elaboration of this rename?
  
 
 See this thread:
 
 https://lkml.org/lkml/2014/11/18/433

Okay, thanks. I  must have missed this one. overlay is as good as a name can 
be, IMHO.

Cheers,
Pete
--
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: new mailing list for union/overlay filesystems?

[Hans-Peter Jansen]

Dear David,

sorry for the late chime in.

On Mittwoch, 25. Juni 2014 15:54:59 David Miller wrote:
> From: Miklos Szeredi 
> Date: Thu, 19 Jun 2014 14:36:50 +0200
> 
> > There's interest in having a mailing list specifically for "union
> > filesystem" like solutions (currently active projects are aufs,
> > union-mounts and overlayfs).
> > 
> > Would it be possible to create one on vger for this purpose?
> 
> I've created linux-unio...@vger.kernel.org

While this is a great move, it's also a little unfortunate, since it is the 
name of exactly one layered filesystem solution out of 4 existing ones 
(ignoring vaporware).

A neutral name would have been linux-layeredfs, and as long as nobody objects, 
I kindly ask you to rename it (as in creating such a ml, and silently phase 
out this one..). Given that 13 people are subscribed by now, that's hopefully 
acceptable for all participants.

BTW, all solutions organize the fs join by layering them. ;)

A layered fs user since about a decade,
Pete

--
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: new mailing list for union/overlay filesystems?

[Hans-Peter Jansen]

Dear David,

sorry for the late chime in.

On Mittwoch, 25. Juni 2014 15:54:59 David Miller wrote:
 From: Miklos Szeredi mik...@szeredi.hu
 Date: Thu, 19 Jun 2014 14:36:50 +0200
 
  There's interest in having a mailing list specifically for union
  filesystem like solutions (currently active projects are aufs,
  union-mounts and overlayfs).
  
  Would it be possible to create one on vger for this purpose?
 
 I've created linux-unio...@vger.kernel.org

While this is a great move, it's also a little unfortunate, since it is the 
name of exactly one layered filesystem solution out of 4 existing ones 
(ignoring vaporware).

A neutral name would have been linux-layeredfs, and as long as nobody objects, 
I kindly ask you to rename it (as in creating such a ml, and silently phase 
out this one..). Given that 13 people are subscribed by now, that's hopefully 
acceptable for all participants.

BTW, all solutions organize the fs join by layering them. ;)

A layered fs user since about a decade,
Pete

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

OT: Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Hans-Peter Jansen]

On Donnerstag, 13. März 2014 14:00:10 Andi Kleen wrote:
 
> At some point the majority of my nfsroot test image were OpenSUSE 9.

Hehe, I had a 9.3 system (2.6.11.4) with an uptime of > 1000 days before power 
outage, and one 11.1 (2.6.27.56), that has an uptime of 1029 days now. While 
git brought in many good aspects, the gain in development speed resulted in 
noticeable decrease of long term stability. And the kernel is a pretty well 
managed project still, compared to other related ones..

> It was the last opensuse system that booted fast without udev or initrd :-)

The ramifications of udev and initrd where tiny, given what systemd has caused 
to openSUSE lately, combined with the (nowadays) usual nfs and autofs 
dysfunctions.. It all made 13.1 sucking rocks. 

SCR,
 Pete

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

OT: Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Hans-Peter Jansen]

On Donnerstag, 13. März 2014 14:00:10 Andi Kleen wrote:
 
 At some point the majority of my nfsroot test image were OpenSUSE 9.

Hehe, I had a 9.3 system (2.6.11.4) with an uptime of  1000 days before power 
outage, and one 11.1 (2.6.27.56), that has an uptime of 1029 days now. While 
git brought in many good aspects, the gain in development speed resulted in 
noticeable decrease of long term stability. And the kernel is a pretty well 
managed project still, compared to other related ones..

 It was the last opensuse system that booted fast without udev or initrd :-)

The ramifications of udev and initrd where tiny, given what systemd has caused 
to openSUSE lately, combined with the (nowadays) usual nfs and autofs 
dysfunctions.. It all made 13.1 sucking rocks. 

SCR,
 Pete

--
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: strange SysRq problem

[Hans-Peter Jansen]

Am Donnerstag, 14. Februar 2008 schrieb Arnd Hannemann:
> Hans-Peter Jansen wrote:
> > I'm suffering from a strange SysRq problem:
> >
> > syslog shows haphazardly "SysRq : HELP" lines, while I definitely
> > didn't triggered them, neither via (PS/2) keyboard, nor via
> > /proc/sysrq-trigger. This is accompanied with stalls of about 15-60
> > secs.
>
> Any chance that a device connected via serial (or an USB device which
> uses USB/Serial conversion) triggers them? My cheap pl2303 device seems
> to send spurious BREAKs every once in a while, which results in the
> described behavior, as the kernel will print the help line for any
> character which is not a valid sysrq. (The probability to trigger another
> sysrq with random data is much lower, but did you find any other printout
> of an sysrq in your logs?)

Hmm, keyboard (Cherry G80-3000 LPCDE-2) and mouse (Logitech RX300) are 
connected via an equip KVM 2 port switch, but everything else is behaving 
properly, and no serial devices connected ATM. It only triggers the help 
messages, other sysrq messages are triggered at will (AFAIKS).

# grep "SysRq : HELP" /var/log/messages | wc -l
814

syslog starts at Jan 16, so you can imagine how disturbing this behavior is.

I cannot outrule some hardware defects. Will start to eliminate the KVM 
switch, but I thought, I ask here before since google also didn't revealed 
any hints..

Thanks,
Pete
--
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: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Hans-Peter Jansen]

Am Donnerstag, 14. Februar 2008 schrieb Borislav Petkov:
> On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
>
> [Added Bart to CC]
>
> > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > > > Hi,
> > > >
> > > > I suffer from unreliable cdrom operations (failing DAE and burn
> > > > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
> > >
> > >   
> > > Hi,
> > >
> > > can please you test this with a more recent kernel. Yours is almost
> > > ancient - from Sep. 2006.
> >
> > Sure, sorry. Here we go:
> >
> > Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused
> > (ireason = 0x01). Trying to recover by ending request.
> > Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused
> > (ireason = 0x01). Trying to recover by ending request.
> >
> > ~> uname -a
> > Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon
> > i386 GNU/Linux
>
> Actually the interrupt handler in ide-cd got rewritten and you're still
> using the old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went
> into mainline before the 2.6.25-rc1 so we'll be able to test the new one
> only when you try out 2.6.25-rc1 or wait until 2.6.25 is released in case
> you don't want to try hazardous materials such as an -rc kernel[*] :).

Hrm, I highly depend on that system being reliable¹, thus I would prefer a 
diff, if feasible at all. That way, any breakage may be embanked to PATA.

OTOH, I'm willing to help to get down to the issue (knowing that this is the 
only way to finally get rid of it).

Thanks,
Pete

¹) As a matter of fact, I suffered from way to many regressions in essential
   subsystems (kernel, X, nss_ldap) lately, not to speak from the usual
   calamities in peripheral areas of such complex beasts.
--
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: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Hans-Peter Jansen]

Am Donnerstag, 14. Februar 2008 schrieb Borislav Petkov:
 On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:

 [Added Bart to CC]

  Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
   On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
Hi,
   
I suffer from unreliable cdrom operations (failing DAE and burn
sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
  
 
   Hi,
  
   can please you test this with a more recent kernel. Yours is almost
   ancient - from Sep. 2006.
 
  Sure, sorry. Here we go:
 
  Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused
  (ireason = 0x01). Trying to recover by ending request.
  Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused
  (ireason = 0x01). Trying to recover by ending request.
 
  ~ uname -a
  Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon
  i386 GNU/Linux

 Actually the interrupt handler in ide-cd got rewritten and you're still
 using the old one (cdrom_pc_intr vs cdrom_newpc_intr). Those changes went
 into mainline before the 2.6.25-rc1 so we'll be able to test the new one
 only when you try out 2.6.25-rc1 or wait until 2.6.25 is released in case
 you don't want to try hazardous materials such as an -rc kernel[*] :).

Hrm, I highly depend on that system being reliable¹, thus I would prefer a 
diff, if feasible at all. That way, any breakage may be embanked to PATA.

OTOH, I'm willing to help to get down to the issue (knowing that this is the 
only way to finally get rid of it).

Thanks,
Pete

¹) As a matter of fact, I suffered from way to many regressions in essential
   subsystems (kernel, X, nss_ldap) lately, not to speak from the usual
   calamities in peripheral areas of such complex beasts.
--
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: strange SysRq problem

[Hans-Peter Jansen]

Am Donnerstag, 14. Februar 2008 schrieb Arnd Hannemann:
 Hans-Peter Jansen wrote:
  I'm suffering from a strange SysRq problem:
 
  syslog shows haphazardly SysRq : HELP lines, while I definitely
  didn't triggered them, neither via (PS/2) keyboard, nor via
  /proc/sysrq-trigger. This is accompanied with stalls of about 15-60
  secs.

 Any chance that a device connected via serial (or an USB device which
 uses USB/Serial conversion) triggers them? My cheap pl2303 device seems
 to send spurious BREAKs every once in a while, which results in the
 described behavior, as the kernel will print the help line for any
 character which is not a valid sysrq. (The probability to trigger another
 sysrq with random data is much lower, but did you find any other printout
 of an sysrq in your logs?)

Hmm, keyboard (Cherry G80-3000 LPCDE-2) and mouse (Logitech RX300) are 
connected via an equip KVM 2 port switch, but everything else is behaving 
properly, and no serial devices connected ATM. It only triggers the help 
messages, other sysrq messages are triggered at will (AFAIKS).

# grep SysRq : HELP /var/log/messages | wc -l
814

syslog starts at Jan 16, so you can imagine how disturbing this behavior is.

I cannot outrule some hardware defects. Will start to eliminate the KVM 
switch, but I thought, I ask here before since google also didn't revealed 
any hints..

Thanks,
Pete
--
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/

strange SysRq problem

[Hans-Peter Jansen]

Hi,

I'm suffering from a strange SysRq problem:

syslog shows haphazardly "SysRq : HELP" lines, while I definitely didn't 
triggered them, neither via (PS/2) keyboard, nor via /proc/sysrq-trigger.
This is accompanied with stalls of about 15-60 secs. 

Here's an example:

Feb 14 00:16:11 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:32:45 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:32:57 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:32:57 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:04 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:33 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 

Anybody suffered from similar behavior out there, and tracked it down?

TIA,
Pete
--
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: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Hans-Peter Jansen]

Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
> > Hi,
> >
> > I suffer from unreliable cdrom operations (failing DAE and burn
> > sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.
>
>   
> Hi,
>
> can please you test this with a more recent kernel. Yours is almost
> ancient - from Sep. 2006.

Sure, sorry. Here we go:

Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01). 
 Trying to recover by ending request.

~> uname -a
Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 
GNU/Linux

Thanks for caring,
Pete
--
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: IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Hans-Peter Jansen]

Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
 On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote:
  Hi,
 
  I suffer from unreliable cdrom operations (failing DAE and burn
  sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel.

   
 Hi,

 can please you test this with a more recent kernel. Yours is almost
 ancient - from Sep. 2006.

Sure, sorry. Here we go:

Feb 14 00:18:18 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 14 00:27:27 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01). 
 Trying to recover by ending request.

~ uname -a
Linux xrated 2.6.24.1-35-pae #1 SMP 2008/02/12 01:00:18 UTC i686 athlon i386 
GNU/Linux

Thanks for caring,
Pete
--
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/

strange SysRq problem

[Hans-Peter Jansen]

Hi,

I'm suffering from a strange SysRq problem:

syslog shows haphazardly SysRq : HELP lines, while I definitely didn't 
triggered them, neither via (PS/2) keyboard, nor via /proc/sysrq-trigger.
This is accompanied with stalls of about 15-60 secs. 

Here's an example:

Feb 14 00:16:11 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:32:45 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:32:57 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:32:57 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:04 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:24 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 
Feb 14 00:33:33 xrated kernel: SysRq : HELP : loglevel0-8 reBoot Crashdump 
tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw 
Sync showTasks Unmount shoW-blocked-tasks 

Anybody suffered from similar behavior out there, and tracked it down?

TIA,
Pete
--
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/

IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Hans-Peter Jansen]

Hi, 

I suffer from unreliable cdrom operations (failing DAE and burn sessions) 
with the openSUSE 2.6.18.8-0.7-bigsmp kernel.

Additionally, the syslog is continuesly spammed with:
 
Feb 12 00:03:22 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 00:57:52 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 01:36:21 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 01:38:49 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 08:06:07 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.

I drove that devices on a pdc20268 based Promise Ultra TX/2 100 card for 
some time, which had some IDE/ATAPI issues documented. After exchanging 
that PCI card with a "Silicon Image PCI0680 based one, the problem persists.

Is there any firmware/atapi protocol problem known with these drives?

These are the offenders:

42: IDE 02.0: 10602 CD-ROM (DVD)
  [Created at block.222]
  UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL
  Unique ID: 90A1.yYhZwSaKZZ6
  Parent ID: ejN_.zzJBQoyZsp8
  SysFS ID: /block/hdc
  SysFS BusID: 1.0
  SysFS Device Link: /devices/pci:00/:00:0e.0/:02:06.0/ide1/1.0
  Hardware Class: cdrom
  Model: "PLEXTOR DVDR PX-608AL"
  Vendor: "PLEXTOR"
  Device: "DVDR PX-608AL"
  Revision: "1.01"
  Serial ID: "GDDL000676UE"
  Driver: "SiI_IDE", "ide-cdrom"
  Driver Modules: "siimage", "ide_cd"
  Device File: /dev/hdc
  Device Files: /dev/hdc, /dev/disk/by-path/pci-:02:06.0-ide-0:0
  Device Number: block 22:0
  Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM
  Drive status: no medium
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #34 (Unknown mass storage controller)
  Drive Speed: 24

43: IDE 04.0: 10602 CD-ROM (DVD)
  [Created at block.222]
  UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL_0
  Unique ID: 3Ng9.rKN6BMng3oC
  Parent ID: ejN_.zzJBQoyZsp8
  SysFS ID: /block/hde
  SysFS BusID: 2.0
  SysFS Device Link: /devices/pci:00/:00:0e.0/:02:06.0/ide2/2.0
  Hardware Class: cdrom
  Model: "PLEXTOR DVDR PX-608AL"
  Vendor: "PLEXTOR"
  Device: "DVDR PX-608AL"
  Revision: "1.01"
  Serial ID: "GGDL007101UE"
  Driver: "SiI_IDE", "ide-cdrom"
  Driver Modules: "siimage", "ide_cd"
  Device File: /dev/hde
  Device Files: /dev/hde, /dev/disk/by-path/pci-:02:06.0-ide-1:0
  Device Number: block 33:0
  Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM
  Drive status: no medium
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #34 (Unknown mass storage controller)
  Drive Speed: 24

hanging on this controller (now):

44: PCI 206.0: 0180 Unknown mass storage controller
  [Created at pci.286]
  UDI: /org/freedesktop/Hal/devices/pci_1095_680
  Unique ID: ejN_.zzJBQoyZsp8
  Parent ID: vuMS.8LoPsVNGJbF
  SysFS ID: /devices/pci:00/:00:0e.0/:02:06.0
  SysFS BusID: :02:06.0
  Hardware Class: storage
  Model: "Silicon Image PCI0680 Ultra ATA-133 Host Controller"
  Vendor: pci 0x1095 "Silicon Image, Inc."
  Device: pci 0x0680 "PCI0680 Ultra ATA-133 Host Controller"
  SubVendor: pci 0x1095 "Silicon Image, Inc."
  SubDevice: pci 0x0680 
  Revision: 0x02
  Driver: "SiI_IDE"
  Driver Modules: "siimage"
  I/O Ports: 0x9c00-0x9c07 (rw)
  I/O Ports: 0x9800-0x9803 (rw)
  I/O Ports: 0x9400-0x9407 (rw)
  I/O Ports: 0x9000-0x9003 (rw)
  I/O Ports: 0x8c00-0x8c0f (rw)
  Memory Range: 0xfdfff000-0xfdfff0ff (rw,non-prefetchable)
  Memory Range: 0xf400-0xf407 (ro,prefetchable,disabled)
  IRQ: 169 (1767334 events)
  Module Alias: "pci:v1095d0680sv1095sd0680bc01sc80i00"
  Driver Info #0:
Driver Status: siimage is active
Driver Activation Cmd: "modprobe siimage"
  Driver Info #1:
Driver Status: pata_sil680 is active
Driver Activation Cmd: "modprobe pata_sil680"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #30 (PCI bridge)

Any hints are highly appreciated.

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

IDE cdrom problem with PLEXTOR DVDR PX-608AL

[Hans-Peter Jansen]

Hi, 

I suffer from unreliable cdrom operations (failing DAE and burn sessions) 
with the openSUSE 2.6.18.8-0.7-bigsmp kernel.

Additionally, the syslog is continuesly spammed with:
 
Feb 12 00:03:22 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 00:57:52 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 01:36:21 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 01:38:49 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.
Feb 12 08:06:07 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason 
= 0x01).
 Trying to recover by ending request.

I drove that devices on a pdc20268 based Promise Ultra TX/2 100 card for 
some time, which had some IDE/ATAPI issues documented. After exchanging 
that PCI card with a Silicon Image PCI0680 based one, the problem persists.

Is there any firmware/atapi protocol problem known with these drives?

These are the offenders:

42: IDE 02.0: 10602 CD-ROM (DVD)
  [Created at block.222]
  UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL
  Unique ID: 90A1.yYhZwSaKZZ6
  Parent ID: ejN_.zzJBQoyZsp8
  SysFS ID: /block/hdc
  SysFS BusID: 1.0
  SysFS Device Link: /devices/pci:00/:00:0e.0/:02:06.0/ide1/1.0
  Hardware Class: cdrom
  Model: PLEXTOR DVDR PX-608AL
  Vendor: PLEXTOR
  Device: DVDR PX-608AL
  Revision: 1.01
  Serial ID: GDDL000676UE
  Driver: SiI_IDE, ide-cdrom
  Driver Modules: siimage, ide_cd
  Device File: /dev/hdc
  Device Files: /dev/hdc, /dev/disk/by-path/pci-:02:06.0-ide-0:0
  Device Number: block 22:0
  Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM
  Drive status: no medium
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #34 (Unknown mass storage controller)
  Drive Speed: 24

43: IDE 04.0: 10602 CD-ROM (DVD)
  [Created at block.222]
  UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL_0
  Unique ID: 3Ng9.rKN6BMng3oC
  Parent ID: ejN_.zzJBQoyZsp8
  SysFS ID: /block/hde
  SysFS BusID: 2.0
  SysFS Device Link: /devices/pci:00/:00:0e.0/:02:06.0/ide2/2.0
  Hardware Class: cdrom
  Model: PLEXTOR DVDR PX-608AL
  Vendor: PLEXTOR
  Device: DVDR PX-608AL
  Revision: 1.01
  Serial ID: GGDL007101UE
  Driver: SiI_IDE, ide-cdrom
  Driver Modules: siimage, ide_cd
  Device File: /dev/hde
  Device Files: /dev/hde, /dev/disk/by-path/pci-:02:06.0-ide-1:0
  Device Number: block 33:0
  Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM
  Drive status: no medium
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #34 (Unknown mass storage controller)
  Drive Speed: 24

hanging on this controller (now):

44: PCI 206.0: 0180 Unknown mass storage controller
  [Created at pci.286]
  UDI: /org/freedesktop/Hal/devices/pci_1095_680
  Unique ID: ejN_.zzJBQoyZsp8
  Parent ID: vuMS.8LoPsVNGJbF
  SysFS ID: /devices/pci:00/:00:0e.0/:02:06.0
  SysFS BusID: :02:06.0
  Hardware Class: storage
  Model: Silicon Image PCI0680 Ultra ATA-133 Host Controller
  Vendor: pci 0x1095 Silicon Image, Inc.
  Device: pci 0x0680 PCI0680 Ultra ATA-133 Host Controller
  SubVendor: pci 0x1095 Silicon Image, Inc.
  SubDevice: pci 0x0680 
  Revision: 0x02
  Driver: SiI_IDE
  Driver Modules: siimage
  I/O Ports: 0x9c00-0x9c07 (rw)
  I/O Ports: 0x9800-0x9803 (rw)
  I/O Ports: 0x9400-0x9407 (rw)
  I/O Ports: 0x9000-0x9003 (rw)
  I/O Ports: 0x8c00-0x8c0f (rw)
  Memory Range: 0xfdfff000-0xfdfff0ff (rw,non-prefetchable)
  Memory Range: 0xf400-0xf407 (ro,prefetchable,disabled)
  IRQ: 169 (1767334 events)
  Module Alias: pci:v1095d0680sv1095sd0680bc01sc80i00
  Driver Info #0:
Driver Status: siimage is active
Driver Activation Cmd: modprobe siimage
  Driver Info #1:
Driver Status: pata_sil680 is active
Driver Activation Cmd: modprobe pata_sil680
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #30 (PCI bridge)

Any hints are highly appreciated.

Pete
--
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: lockd spams syslog after upgrade from 2.6.18 to 2.6.24-rc8

[Hans-Peter Jansen]

Am Montag, 21. Januar 2008 schrieb Hans-Peter Jansen:
> Hi,
>
> after installation of 2.6.24-rc8 on a local server, the syslog gets
> spammed with "lockd: cannot monitor "
>
> grep 'lockd: cannot monitor' /var/log/messages | wc -l
> 136026
>
> in 20 minutes! I restarted the offending client (with 2.6.18.something)
> for mercy reasons now..
>
> Pete

I got even worser today. This server provides nfs3 mounted home directories
for a small network, but working with OpenOffice is unpossible. Loading a
file looks fine, it get displayed properly, but then it hangs, before being
able to do anything. Killing removes the process. Reverting to 
2.6.18.something on the server fixed both issues. Client and server are 
openSUSE 10.2 installations.

As it stands, 2.6.24-rc8 isn't usable for me at the moment. Let me know, if
I can provide more details for these issues.

Pete

Here's the OpenOffice call trace:

Jan 21 12:34:26 xrated kernel: soffice.bin   S D18AB017 0 18589  1  
   18590 16736 (NOTLB)
Jan 21 12:34:26 xrated kernel:d6065e80 00200086 d6d643a8 d18ab017 
c01700ee d6065e50 0007 e7b6d230 
Jan 21 12:34:26 xrated kernel:b175be00 80cb   
e7b6d360 c34126e0 b7580900  
Jan 21 12:34:26 xrated kernel:00200082 f1a4bf44 f1a4bf1c  
d6065e5c c0119b87  b6b2be6c 
Jan 21 12:34:26 xrated kernel: Call Trace:
Jan 21 12:34:26 xrated kernel:  [] do_lookup+0x4f/0x135
Jan 21 12:34:26 xrated kernel:  [] __wake_up_common+0x2f/0x53
Jan 21 12:34:26 xrated kernel:  [] schedule_timeout+0x13/0x98
Jan 21 12:34:26 xrated kernel:  [] get_futex_key+0x40/0xee
Jan 21 12:34:26 xrated kernel:  [] vfs_statfs+0x47/0x5f
Jan 21 12:34:26 xrated kernel:  [] add_wait_queue+0x12/0x30
Jan 21 12:34:26 xrated kernel:  [] do_futex+0x1b4/0xafb
Jan 21 12:34:26 xrated kernel:  [] _atomic_dec_and_lock+0x2a/0x44
Jan 21 12:34:26 xrated kernel:  [] mntput_no_expire+0x11/0x6a
Jan 21 12:34:26 xrated kernel:  [] sys_statfs64+0x75/0x80
Jan 21 12:34:26 xrated kernel:  [] default_wake_function+0x0/0xc
Jan 21 12:34:26 xrated kernel:  [] sys_futex+0xed/0x100
Jan 21 12:34:26 xrated kernel:  [] sys_clone+0x36/0x3b
Jan 21 12:34:26 xrated kernel:  [] syscall_call+0x7/0xb
Jan 21 12:34:26 xrated kernel: soffice.bin   S 80CA 0 18590  1  
   18591 18589 (NOTLB)
Jan 21 12:34:26 xrated kernel:d6f4fe80 0086 37910500 80ca 
0086 c011b185 0001 e7b6ccb0 
Jan 21 12:34:26 xrated kernel:37ce0e00 80ca  0001 
e7b6cde0 c341a6e0   
Jan 21 12:34:26 xrated kernel: c0178d7a  d643b670 
 d6f4fe5a 000a c02c77aa 
Jan 21 12:34:26 xrated kernel: Call Trace:
Jan 21 12:34:26 xrated kernel:  [] try_to_wake_up+0x365/0x36f
Jan 21 12:34:26 xrated kernel:  [] dput+0x22/0x123
Jan 21 12:34:26 xrated kernel:  [] schedule_timeout+0x79/0x98
Jan 21 12:34:26 xrated kernel:  [] get_futex_key+0x40/0xee
Jan 21 12:34:26 xrated kernel:  [] futex_wake+0xa9/0xb3
Jan 21 12:34:26 xrated kernel:  [] process_timeout+0x0/0x5
Jan 21 12:34:26 xrated kernel:  [] do_futex+0x1b4/0xafb
Jan 21 12:34:26 xrated kernel:  [] sys_exit_group+0x0/0xd
Jan 21 12:34:26 xrated kernel:  [] get_signal_to_deliver+0x395/0x3bc
Jan 21 12:34:26 xrated kernel:  [] do_notify_resume+0x76/0x5ee
Jan 21 12:34:26 xrated kernel:  [] default_wake_function+0x0/0xc
Jan 21 12:34:26 xrated kernel:  [] sys_futex+0xed/0x100
Jan 21 12:34:26 xrated kernel:  [] syscall_call+0x7/0xb
Jan 21 12:34:26 xrated kernel: soffice.bin   S C3652C70 0 18591  1  
   18593 18590 (NOTLB)
Jan 21 12:34:26 xrated kernel:e9307e54 0086 c36f5680 c3652c70 
00e438d0 c02b35a0 0001 c3652c70 
Jan 21 12:34:26 xrated kernel:38ff3b00 80ca  0001 
c3652da0 c341a6e0   
Jan 21 12:34:26 xrated kernel:c011b185 0001 c3652c70 0163 
 c25ded20  c25ded20 
Jan 21 12:34:26 xrated kernel: Call Trace:
Jan 21 12:34:26 xrated kernel:  [] try_to_wake_up+0x365/0x36f
Jan 21 12:34:26 xrated kernel:  [] schedule_timeout+0x13/0x98
Jan 21 12:34:26 xrated kernel:  [] inotify_d_instantiate+0x41/0x67
Jan 21 12:34:26 xrated kernel:  [] d_alloc+0x142/0x18f
Jan 21 12:34:26 xrated kernel:  [] prepare_to_wait_exclusive+0x12/0x4b
Jan 21 12:34:26 xrated kernel:  [] skb_recv_datagram+0x130/0x1af
Jan 21 12:34:26 xrated kernel:  [] autoremove_wake_function+0x0/0x35
Jan 21 12:34:26 xrated kernel:  [] unix_accept+0x4f/0xd6
Jan 21 12:34:26 xrated kernel:  [] sys_accept+0xf6/0x1c8
Jan 21 12:34:26 xrated kernel:  [] sys_socketcall+0xd6/0x261
Jan 21 12:34:26 xrated kernel:  [] syscall_call+0x7/0xb
Jan 21 12:34:26 xrated kernel: soffice.bin   S  0 18593  1  
   18598 18591 (NOTLB)
Jan 21 12:34:26 xrated kernel:d631dbfc 00200086   
  0001 f50736b0 
Jan 21 12:34:26 xrated kernel:596c0300 80ca  0001 
f50737e0 c341a6e0 00

Re: lockd spams syslog after upgrade from 2.6.18 to 2.6.24-rc8

[Hans-Peter Jansen]

Am Montag, 21. Januar 2008 schrieb Hans-Peter Jansen:
 Hi,

 after installation of 2.6.24-rc8 on a local server, the syslog gets
 spammed with lockd: cannot monitor some client

 grep 'lockd: cannot monitor' /var/log/messages | wc -l
 136026

 in 20 minutes! I restarted the offending client (with 2.6.18.something)
 for mercy reasons now..

 Pete

I got even worser today. This server provides nfs3 mounted home directories
for a small network, but working with OpenOffice is unpossible. Loading a
file looks fine, it get displayed properly, but then it hangs, before being
able to do anything. Killing removes the process. Reverting to 
2.6.18.something on the server fixed both issues. Client and server are 
openSUSE 10.2 installations.

As it stands, 2.6.24-rc8 isn't usable for me at the moment. Let me know, if
I can provide more details for these issues.

Pete

Here's the OpenOffice call trace:

Jan 21 12:34:26 xrated kernel: soffice.bin   S D18AB017 0 18589  1  
   18590 16736 (NOTLB)
Jan 21 12:34:26 xrated kernel:d6065e80 00200086 d6d643a8 d18ab017 
c01700ee d6065e50 0007 e7b6d230 
Jan 21 12:34:26 xrated kernel:b175be00 80cb   
e7b6d360 c34126e0 b7580900  
Jan 21 12:34:26 xrated kernel:00200082 f1a4bf44 f1a4bf1c  
d6065e5c c0119b87  b6b2be6c 
Jan 21 12:34:26 xrated kernel: Call Trace:
Jan 21 12:34:26 xrated kernel:  [c01700ee] do_lookup+0x4f/0x135
Jan 21 12:34:26 xrated kernel:  [c0119b87] __wake_up_common+0x2f/0x53
Jan 21 12:34:26 xrated kernel:  [c02a60f5] schedule_timeout+0x13/0x98
Jan 21 12:34:26 xrated kernel:  [c013535e] get_futex_key+0x40/0xee
Jan 21 12:34:26 xrated kernel:  [c0162d6b] vfs_statfs+0x47/0x5f
Jan 21 12:34:26 xrated kernel:  [c0132772] add_wait_queue+0x12/0x30
Jan 21 12:34:26 xrated kernel:  [c0136394] do_futex+0x1b4/0xafb
Jan 21 12:34:26 xrated kernel:  [c01bfc16] _atomic_dec_and_lock+0x2a/0x44
Jan 21 12:34:26 xrated kernel:  [c017c523] mntput_no_expire+0x11/0x6a
Jan 21 12:34:26 xrated kernel:  [c0163e6f] sys_statfs64+0x75/0x80
Jan 21 12:34:26 xrated kernel:  [c011b18f] default_wake_function+0x0/0xc
Jan 21 12:34:26 xrated kernel:  [c0136dc8] sys_futex+0xed/0x100
Jan 21 12:34:26 xrated kernel:  [c01022f0] sys_clone+0x36/0x3b
Jan 21 12:34:26 xrated kernel:  [c0103e47] syscall_call+0x7/0xb
Jan 21 12:34:26 xrated kernel: soffice.bin   S 80CA 0 18590  1  
   18591 18589 (NOTLB)
Jan 21 12:34:26 xrated kernel:d6f4fe80 0086 37910500 80ca 
0086 c011b185 0001 e7b6ccb0 
Jan 21 12:34:26 xrated kernel:37ce0e00 80ca  0001 
e7b6cde0 c341a6e0   
Jan 21 12:34:26 xrated kernel: c0178d7a  d643b670 
 d6f4fe5a 000a c02c77aa 
Jan 21 12:34:26 xrated kernel: Call Trace:
Jan 21 12:34:26 xrated kernel:  [c011b185] try_to_wake_up+0x365/0x36f
Jan 21 12:34:26 xrated kernel:  [c0178d7a] dput+0x22/0x123
Jan 21 12:34:26 xrated kernel:  [c02a615b] schedule_timeout+0x79/0x98
Jan 21 12:34:26 xrated kernel:  [c013535e] get_futex_key+0x40/0xee
Jan 21 12:34:26 xrated kernel:  [c01357d3] futex_wake+0xa9/0xb3
Jan 21 12:34:26 xrated kernel:  [c012933e] process_timeout+0x0/0x5
Jan 21 12:34:26 xrated kernel:  [c0136394] do_futex+0x1b4/0xafb
Jan 21 12:34:26 xrated kernel:  [c01242c3] sys_exit_group+0x0/0xd
Jan 21 12:34:26 xrated kernel:  [c012c37b] get_signal_to_deliver+0x395/0x3bc
Jan 21 12:34:26 xrated kernel:  [c0103526] do_notify_resume+0x76/0x5ee
Jan 21 12:34:26 xrated kernel:  [c011b18f] default_wake_function+0x0/0xc
Jan 21 12:34:26 xrated kernel:  [c0136dc8] sys_futex+0xed/0x100
Jan 21 12:34:26 xrated kernel:  [c0103e47] syscall_call+0x7/0xb
Jan 21 12:34:26 xrated kernel: soffice.bin   S C3652C70 0 18591  1  
   18593 18590 (NOTLB)
Jan 21 12:34:26 xrated kernel:e9307e54 0086 c36f5680 c3652c70 
00e438d0 c02b35a0 0001 c3652c70 
Jan 21 12:34:26 xrated kernel:38ff3b00 80ca  0001 
c3652da0 c341a6e0   
Jan 21 12:34:26 xrated kernel:c011b185 0001 c3652c70 0163 
 c25ded20  c25ded20 
Jan 21 12:34:26 xrated kernel: Call Trace:
Jan 21 12:34:26 xrated kernel:  [c011b185] try_to_wake_up+0x365/0x36f
Jan 21 12:34:26 xrated kernel:  [c02a60f5] schedule_timeout+0x13/0x98
Jan 21 12:34:26 xrated kernel:  [c0187996] inotify_d_instantiate+0x41/0x67
Jan 21 12:34:26 xrated kernel:  [c0178c83] d_alloc+0x142/0x18f
Jan 21 12:34:26 xrated kernel:  [c0132678] prepare_to_wait_exclusive+0x12/0x4b
Jan 21 12:34:26 xrated kernel:  [c02521b1] skb_recv_datagram+0x130/0x1af
Jan 21 12:34:26 xrated kernel:  [c01325aa] autoremove_wake_function+0x0/0x35
Jan 21 12:34:26 xrated kernel:  [c02a2b4b] unix_accept+0x4f/0xd6
Jan 21 12:34:26 xrated kernel:  [c024c6de] sys_accept+0xf6/0x1c8
Jan 21 12:34:26 xrated kernel:  [c024c886] sys_socketcall+0xd6/0x261
Jan 21 12:34:26 xrated kernel:  [c0103e47] syscall_call+0x7/0xb
Jan 21 12:34:26 xrated kernel: soffice.bin   S 

lockd spams syslog after upgrade from 2.6.18 to 2.6.24-rc8

[Hans-Peter Jansen]

Hi, 

after installation of 2.6.24-rc8 on a local server, the syslog gets spammed 
with "lockd: cannot monitor "

grep 'lockd: cannot monitor' /var/log/messages | wc -l
136026

in 20 minutes! I restarted the offending client (with 2.6.18.something) for 
mercy reasons now..

Pete
--
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 device ordering at boot time

[Hans-Peter Jansen]

Dear Alan, dear kernel & dvb hackers,

Am Sonntag, 20. Januar 2008 schrieb Alan Cox:
> > Well, it's a major pain in the a**. I've no idea, what reversed the
> > order of PCI devices, but I had to disable the automatic dvb driver
> > loading in order
>
> It depends on the order you load the modules

Sure, but given, that userspace didn't changed meanwhile, I relied on some 
hotplug figure before (in openSUSE 10.2 with 2.6.18) to load the modules in 
the correct order which itself surely enumerates the PCI bus in some way.

After switching to 2.6.24-rc this order was reversed. At least, my budget 
card was first now, while the ff dvb card second, which resulted in a 
working vdr, unfortunately without picture and sound (that dropped the WAF 
immensely 8-|). 

I solved this issue by blacklisting both cards in /etc/modprobe.d/blacklist, 
and manually determined the order and which modules to load, only to 
discover, that the system won't wake up on the scheduled times anymore. 
Ahh, /proc/acpi/alarm disappeared and needed adaption 
to /sys/class/rtc/rtc0/wakealarm. That move seems to have (yet to examine, 
but easy to work around) timezone issues. On the bright side, this new 
interface doesn't interfere with setting the c-mos clock on power down 
anymore. One gross hack down. Cool.

The last regressions awaiting to get tackled are:
 - rewind is somewhat broken: after a few seconds rewinding correctly, the
   pictures stutter, and vdr uses cpu like mad.
 - from time to time, the same happens for a few seconds on simple replay.

Both issues _feel_ like locking artefacts, which 2.6.18 (with 
http://linuxtv.org/hg/v4l-dvb drivers) didn't suffer from (my vdr operates 
mostly on nfs3 mounted files). I'm trying to explore these problems in more 
detail and will come back. For the record, these issues happen with the 
factory drivers/media modules and with drivers from v4l-dvb tree.

Please don't get me wrong, I'm not whining about all this, it's just a 
report from user side about what happens, if one tries to follow a strong 
moving target. Take it as a reminder, that some decisions during (kernel) 
development does have an wider impact on us poor users out there, as it 
seems.

The only thing, what makes me really sad, is that current dvb development is 
distracted by political and emotional (ego-logical) reasons, repressing  
the full potential in this area.

Pete
--
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 device ordering at boot time

[Hans-Peter Jansen]

Dear Alan, dear kernel  dvb hackers,

Am Sonntag, 20. Januar 2008 schrieb Alan Cox:
  Well, it's a major pain in the a**. I've no idea, what reversed the
  order of PCI devices, but I had to disable the automatic dvb driver
  loading in order

 It depends on the order you load the modules

Sure, but given, that userspace didn't changed meanwhile, I relied on some 
hotplug figure before (in openSUSE 10.2 with 2.6.18) to load the modules in 
the correct order which itself surely enumerates the PCI bus in some way.

After switching to 2.6.24-rc this order was reversed. At least, my budget 
card was first now, while the ff dvb card second, which resulted in a 
working vdr, unfortunately without picture and sound (that dropped the WAF 
immensely 8-|). 

I solved this issue by blacklisting both cards in /etc/modprobe.d/blacklist, 
and manually determined the order and which modules to load, only to 
discover, that the system won't wake up on the scheduled times anymore. 
Ahh, /proc/acpi/alarm disappeared and needed adaption 
to /sys/class/rtc/rtc0/wakealarm. That move seems to have (yet to examine, 
but easy to work around) timezone issues. On the bright side, this new 
interface doesn't interfere with setting the c-mos clock on power down 
anymore. One gross hack down. Cool.

The last regressions awaiting to get tackled are:
 - rewind is somewhat broken: after a few seconds rewinding correctly, the
   pictures stutter, and vdr uses cpu like mad.
 - from time to time, the same happens for a few seconds on simple replay.

Both issues _feel_ like locking artefacts, which 2.6.18 (with 
http://linuxtv.org/hg/v4l-dvb drivers) didn't suffer from (my vdr operates 
mostly on nfs3 mounted files). I'm trying to explore these problems in more 
detail and will come back. For the record, these issues happen with the 
factory drivers/media modules and with drivers from v4l-dvb tree.

Please don't get me wrong, I'm not whining about all this, it's just a 
report from user side about what happens, if one tries to follow a strong 
moving target. Take it as a reminder, that some decisions during (kernel) 
development does have an wider impact on us poor users out there, as it 
seems.

The only thing, what makes me really sad, is that current dvb development is 
distracted by political and emotional (ego-logical) reasons, repressing  
the full potential in this area.

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

lockd spams syslog after upgrade from 2.6.18 to 2.6.24-rc8

[Hans-Peter Jansen]

Hi, 

after installation of 2.6.24-rc8 on a local server, the syslog gets spammed 
with lockd: cannot monitor some client

grep 'lockd: cannot monitor' /var/log/messages | wc -l
136026

in 20 minutes! I restarted the offending client (with 2.6.18.something) for 
mercy reasons now..

Pete
--
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 device ordering at boot time

[Hans-Peter Jansen]

Am Samstag, 19. Januar 2008 schrieben Sie:
> I have a question concerning the ordering of devices during the boot
> process and I hope that the kernel mailing list is the right place for
> this question. In my computer are two raid controllers with one raid
> array connected to each of them (/dev/sda, /dev/sdb). In the debian
> 2.6.18 boot process the ordering is root @ /dev/sda and data are on
> /dev/sdb. This behaviour has changed in the plain 2.6.23.1 (and 2.6.23.8)
> kernel. The /dev/sd(a|b) devices have switched so that root @ /dev/sdb.
> So my standard fstab does not work. What determines the device ordering
> during the boot process? What is a workaround for this problem?

Well, it's a major pain in the a**. I've no idea, what reversed the order of 
PCI devices, but I had to disable the automatic dvb driver loading in order 
to get the picture back (dedicated vdr system with one FF and one budget 
card). I could have taken the route of exchanging the cards, but that would 
have been even more painful..

Oh well,
Pete

--
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 device ordering at boot time

[Hans-Peter Jansen]

Am Samstag, 19. Januar 2008 schrieben Sie:
 I have a question concerning the ordering of devices during the boot
 process and I hope that the kernel mailing list is the right place for
 this question. In my computer are two raid controllers with one raid
 array connected to each of them (/dev/sda, /dev/sdb). In the debian
 2.6.18 boot process the ordering is root @ /dev/sda and data are on
 /dev/sdb. This behaviour has changed in the plain 2.6.23.1 (and 2.6.23.8)
 kernel. The /dev/sd(a|b) devices have switched so that root @ /dev/sdb.
 So my standard fstab does not work. What determines the device ordering
 during the boot process? What is a workaround for this problem?

Well, it's a major pain in the a**. I've no idea, what reversed the order of 
PCI devices, but I had to disable the automatic dvb driver loading in order 
to get the picture back (dedicated vdr system with one FF and one budget 
card). I could have taken the route of exchanging the cards, but that would 
have been even more painful..

Oh well,
Pete

--
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 PATCHES] V4L/DVB fixes

[Hans-Peter Jansen]

Am Montag, 7. Januar 2008 schrieb Mauro Carvalho Chehab:
>
> Hans Verkuil (1):
>   V4L/DVB (6916): ivtv: udelay has to be changed *after* the eeprom
> was read, not before

boils down to this patch:

89dab3573aa1d95fd222ee4551f964bfa4c16823
 drivers/media/video/ivtv/ivtv-driver.c |4 
 drivers/media/video/ivtv/ivtv-i2c.c|5 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-driver.c 
b/drivers/media/video/ivtv/ivtv-driver.c
index 6d2dd87..10d6faf 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -1076,6 +1076,10 @@ static int __devinit ivtv_probe(struct pci_dev *dev,
ivtv_process_eeprom(itv);
}
 
+   /* The mspx4xx chips need a longer delay for some reason */
+   if (!(itv->hw_flags & IVTV_HW_MSP34XX))
+   itv->i2c_algo.udelay = 5;
+
if (itv->std == 0) {
itv->std = V4L2_STD_NTSC_M;
}
diff --git a/drivers/media/video/ivtv/ivtv-i2c.c 
b/drivers/media/video/ivtv/ivtv-i2c.c
index 44678fe..36e54f7 100644
--- a/drivers/media/video/ivtv/ivtv-i2c.c
+++ b/drivers/media/video/ivtv/ivtv-i2c.c
@@ -541,7 +541,7 @@ static const struct i2c_algo_bit_data 
ivtv_i2c_algo_template = {
.setscl = ivtv_setscl_old,
.getsda = ivtv_getsda_old,
.getscl = ivtv_getscl_old,
-   .udelay = 5,
+   .udelay = 10,
.timeout= 200,
 };
 
@@ -718,9 +718,6 @@ int init_ivtv_i2c(struct ivtv *itv)
   sizeof(struct i2c_adapter));
memcpy(>i2c_algo, _i2c_algo_template,
   sizeof(struct i2c_algo_bit_data));
-   /* The mspx4xx chips need a longer delay for some reason */
-   if (itv->hw_flags & IVTV_HW_MSP34XX)
-   itv->i2c_algo.udelay = 10;
itv->i2c_algo.data = itv;
itv->i2c_adap.algo_data = >i2c_algo;
}

where the logic in hunk #1 was switched, resulting in a now misleading 
comment over there.

How about something in the line of:

/* 
 * We started with a bigger udelay in order to fulfill the needs of the
 * mspx4xx chips: cut it down here for all other members of the family.
 */

Cheers,
Pete
--
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 PATCHES] V4L/DVB fixes

[Hans-Peter Jansen]

Am Montag, 7. Januar 2008 schrieb Mauro Carvalho Chehab:

 Hans Verkuil (1):
   V4L/DVB (6916): ivtv: udelay has to be changed *after* the eeprom
 was read, not before

boils down to this patch:

89dab3573aa1d95fd222ee4551f964bfa4c16823
 drivers/media/video/ivtv/ivtv-driver.c |4 
 drivers/media/video/ivtv/ivtv-i2c.c|5 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/ivtv/ivtv-driver.c 
b/drivers/media/video/ivtv/ivtv-driver.c
index 6d2dd87..10d6faf 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -1076,6 +1076,10 @@ static int __devinit ivtv_probe(struct pci_dev *dev,
ivtv_process_eeprom(itv);
}
 
+   /* The mspx4xx chips need a longer delay for some reason */
+   if (!(itv-hw_flags  IVTV_HW_MSP34XX))
+   itv-i2c_algo.udelay = 5;
+
if (itv-std == 0) {
itv-std = V4L2_STD_NTSC_M;
}
diff --git a/drivers/media/video/ivtv/ivtv-i2c.c 
b/drivers/media/video/ivtv/ivtv-i2c.c
index 44678fe..36e54f7 100644
--- a/drivers/media/video/ivtv/ivtv-i2c.c
+++ b/drivers/media/video/ivtv/ivtv-i2c.c
@@ -541,7 +541,7 @@ static const struct i2c_algo_bit_data 
ivtv_i2c_algo_template = {
.setscl = ivtv_setscl_old,
.getsda = ivtv_getsda_old,
.getscl = ivtv_getscl_old,
-   .udelay = 5,
+   .udelay = 10,
.timeout= 200,
 };
 
@@ -718,9 +718,6 @@ int init_ivtv_i2c(struct ivtv *itv)
   sizeof(struct i2c_adapter));
memcpy(itv-i2c_algo, ivtv_i2c_algo_template,
   sizeof(struct i2c_algo_bit_data));
-   /* The mspx4xx chips need a longer delay for some reason */
-   if (itv-hw_flags  IVTV_HW_MSP34XX)
-   itv-i2c_algo.udelay = 10;
itv-i2c_algo.data = itv;
itv-i2c_adap.algo_data = itv-i2c_algo;
}

where the logic in hunk #1 was switched, resulting in a now misleading 
comment over there.

How about something in the line of:

/* 
 * We started with a bigger udelay in order to fulfill the needs of the
 * mspx4xx chips: cut it down here for all other members of the family.
 */

Cheers,
Pete
--
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/11] writeback bug fixes and simplifications

[Hans-Peter Jansen]

Am Freitag, 28. Dezember 2007 schrieb Sascha Warner:
> Andrew Morton wrote:
> > On Thu, 27 Dec 2007 23:08:40 +0100 Sascha Warner <[EMAIL PROTECTED]> 
wrote:
> >> Hi,
> >>
> >> I applied your patches to 2.6.24-rc6-mm1, but now I am faced with one
> >> pdflush often using 100% CPU for a long time. There seem to be some
> >> rare pauses from its 100% usage, however.
> >>
> >> On ~23 minutes uptime i have ~19 minutes pdflush runtime.
> >>
> >> This is on E6600, x86_64, 2 Gig RAM, SATA HDD, running on gentoo
> >> ~x64_64
> >>
> >> Let me know if you need more info.
> >
> > (some) cc's restored.  Please, always do reply-to-all.
>
> Hi Wu,

Sascha, if you want to address Fengguang by his first name, note that 
chinese and bavarians (and some others I forgot now, too) typically use the 
order:
  
  lastname firstname 

when they spell their names. Another evidence is, that the name Wu is a 
pretty common chinese family name.

Fengguang, if it's the other way around, correct me please (and I'm going to 
wear a big brown paper bag for the rest of the day..). 

> Your latest patch does fix the seen pdflush 100% issue :)
>
> P.S.: Andrew, sorry my subject pretended I was subscribed to lkml, I am
> not. I hoped for the script at lkml to pull the threads together because
> of the subject.

Such a script _cannot_ exist for a mailing list. Sane mailing list software 
mangles messages in the least intrusive way and highly depend on users 
doing the right thing. In this case, that's what Sam suggested below!

A-happy-new-year-for-all-kernel-hacking-heros-ly-yrs,

Pete
--
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/11] writeback bug fixes and simplifications

[Hans-Peter Jansen]

Am Freitag, 28. Dezember 2007 schrieb Sascha Warner:
 Andrew Morton wrote:
  On Thu, 27 Dec 2007 23:08:40 +0100 Sascha Warner [EMAIL PROTECTED] 
wrote:
  Hi,
 
  I applied your patches to 2.6.24-rc6-mm1, but now I am faced with one
  pdflush often using 100% CPU for a long time. There seem to be some
  rare pauses from its 100% usage, however.
 
  On ~23 minutes uptime i have ~19 minutes pdflush runtime.
 
  This is on E6600, x86_64, 2 Gig RAM, SATA HDD, running on gentoo
  ~x64_64
 
  Let me know if you need more info.
 
  (some) cc's restored.  Please, always do reply-to-all.

 Hi Wu,

Sascha, if you want to address Fengguang by his first name, note that 
chinese and bavarians (and some others I forgot now, too) typically use the 
order:
  
  lastname firstname 

when they spell their names. Another evidence is, that the name Wu is a 
pretty common chinese family name.

Fengguang, if it's the other way around, correct me please (and I'm going to 
wear a big brown paper bag for the rest of the day..). 

 Your latest patch does fix the seen pdflush 100% issue :)

 P.S.: Andrew, sorry my subject pretended I was subscribed to lkml, I am
 not. I hoped for the script at lkml to pull the threads together because
 of the subject.

Such a script _cannot_ exist for a mailing list. Sane mailing list software 
mangles messages in the least intrusive way and highly depend on users 
doing the right thing. In this case, that's what Sam suggested below!

A-happy-new-year-for-all-kernel-hacking-heros-ly-yrs,

Pete
--
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: arcmsr changelog differs from diffs

[Hans-Peter Jansen]

Dear Björn,

Am Mittwoch, 17. Oktober 2007 02:53 schrieb Björn Steinbrink:
> On 2007.10.17 00:07:19 +0200, Hans-Peter Jansen wrote:
> > Hi Jeff,
> >
> > while browsing through Linus' current check ins, I stumbled upon:
> >
> > [SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:
> >
> > --8<--
> > 488a5c8a9a3b67ae117784cd0d73bef53a73d57d
> >  drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
> > b/drivers/scsi/arcmsr/arcmsr_hba.c
> > index 7832a10..f4d2d52 100644
> > --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> > +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> > @@ -422,7 +422,7 @@ static int arcmsr_probe(struct pci_dev *pdev,
> > goto out_release_regions;
> >
> > error = request_irq(pdev->irq, arcmsr_do_interrupt,
> > -   IRQF_SHARED, "arcmsr", acb);
> > +   IRQF_SHARED, "arcmsr", acb);
> > if (error)
> > goto out_free_ccb_pool;
> >
> > -->8--
> >
> > and: [SCSI] arcmsr: Fix hardware wait loops
> >
> > --8<--
> > 24430458bb924e371ff894e26bfa9f73707f53fb
> >  drivers/scsi/arcmsr/arcmsr_hba.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
> > b/drivers/scsi/arcmsr/arcmsr_hba.c
> > index 50e1310..7832a10 100644
> > --- a/drivers/scsi/arcmsr/arcmsr_hba.c
> > +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
> > @@ -2092,8 +2092,10 @@ static void arcmsr_iop_reset(struct
> > AdapterControlBlock *acb)
> > if (atomic_read(>ccboutstandingcount) != 0) {
> > /* talk to iop 331 outstanding command aborted */
> > arcmsr_abort_allcmd(acb);
> > +
> > /* wait for 3 sec for all command aborted*/
> > ssleep(3);
> > +
> > /* disable all outbound interrupt */
> > intmask_org = arcmsr_disable_outbound_ints(acb);
> > /* clear all outbound posted Q */
> > -->8--
> >
> > where both changelogs differ significantly from the actual diffs, which
> > both are simple WS fixups and nothing else. Does qgit fools me here, or
> > is anything else wrong on my side?
>
> Nothing wrong on your side. I took a look at the second one, and
> everything but the whitespace changes already found its way into Linus'
> tree via 1a4f550a09f89e3a15eff1971bc9db977571b9f6. One hunk of the
> original patch[1] was actually made redundant because the code was
> removed in that commit, so that's probably what James fixed (see full
> commit message).

Yup, I found the patch you mentioned also, but that time orginating from 
Nick Cheng (*).

That diff is unfortunately way too big for me to be able to decide, if it's 
worth it to replace a former instance of arcmsr-1.20.0.13 for a 2.6.18.8 
kernel, which I use and essentially depend on here.

Thus I decided now to bluntly cc Nick and ask directly this way:
Nick, does 1.20.0.15 provide any essential changes over 1.20.0.13 for a 
ARC-1130 with FW 1.41 (2006-05-24), which advise updating?

> And then, if I may guess, James probably just noticed that there were
> changes left and commited them (while they were now down to just the
> whitespace change), without checking what changes were actually left (no
> offense intended). At least I think that git wouldn't cripple the diff
> if the changes that James checked in were not already whitespace-only at
> the time he commited them, and the git history of his tree seems to
> agree.

(*) Thanks for the clarification, Björn. What made me stumbling was the 
different orginators, while Jeff isn't known with catching attention by 
assimilating other peoples contributions. 

> Probably the other commit is similar.
>
> Björn
>
> [1] http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg11957.html

Pete
-
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: arcmsr changelog differs from diffs

[Hans-Peter Jansen]

Dear Björn,

Am Mittwoch, 17. Oktober 2007 02:53 schrieb Björn Steinbrink:
 On 2007.10.17 00:07:19 +0200, Hans-Peter Jansen wrote:
  Hi Jeff,
 
  while browsing through Linus' current check ins, I stumbled upon:
 
  [SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:
 
  --8--
  488a5c8a9a3b67ae117784cd0d73bef53a73d57d
   drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
 
  diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
  b/drivers/scsi/arcmsr/arcmsr_hba.c
  index 7832a10..f4d2d52 100644
  --- a/drivers/scsi/arcmsr/arcmsr_hba.c
  +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
  @@ -422,7 +422,7 @@ static int arcmsr_probe(struct pci_dev *pdev,
  goto out_release_regions;
 
  error = request_irq(pdev-irq, arcmsr_do_interrupt,
  -   IRQF_SHARED, arcmsr, acb);
  +   IRQF_SHARED, arcmsr, acb);
  if (error)
  goto out_free_ccb_pool;
 
  --8--
 
  and: [SCSI] arcmsr: Fix hardware wait loops
 
  --8--
  24430458bb924e371ff894e26bfa9f73707f53fb
   drivers/scsi/arcmsr/arcmsr_hba.c |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c
  b/drivers/scsi/arcmsr/arcmsr_hba.c
  index 50e1310..7832a10 100644
  --- a/drivers/scsi/arcmsr/arcmsr_hba.c
  +++ b/drivers/scsi/arcmsr/arcmsr_hba.c
  @@ -2092,8 +2092,10 @@ static void arcmsr_iop_reset(struct
  AdapterControlBlock *acb)
  if (atomic_read(acb-ccboutstandingcount) != 0) {
  /* talk to iop 331 outstanding command aborted */
  arcmsr_abort_allcmd(acb);
  +
  /* wait for 3 sec for all command aborted*/
  ssleep(3);
  +
  /* disable all outbound interrupt */
  intmask_org = arcmsr_disable_outbound_ints(acb);
  /* clear all outbound posted Q */
  --8--
 
  where both changelogs differ significantly from the actual diffs, which
  both are simple WS fixups and nothing else. Does qgit fools me here, or
  is anything else wrong on my side?

 Nothing wrong on your side. I took a look at the second one, and
 everything but the whitespace changes already found its way into Linus'
 tree via 1a4f550a09f89e3a15eff1971bc9db977571b9f6. One hunk of the
 original patch[1] was actually made redundant because the code was
 removed in that commit, so that's probably what James fixed (see full
 commit message).

Yup, I found the patch you mentioned also, but that time orginating from 
Nick Cheng (*).

That diff is unfortunately way too big for me to be able to decide, if it's 
worth it to replace a former instance of arcmsr-1.20.0.13 for a 2.6.18.8 
kernel, which I use and essentially depend on here.

Thus I decided now to bluntly cc Nick and ask directly this way:
Nick, does 1.20.0.15 provide any essential changes over 1.20.0.13 for a 
ARC-1130 with FW 1.41 (2006-05-24), which advise updating?

 And then, if I may guess, James probably just noticed that there were
 changes left and commited them (while they were now down to just the
 whitespace change), without checking what changes were actually left (no
 offense intended). At least I think that git wouldn't cripple the diff
 if the changes that James checked in were not already whitespace-only at
 the time he commited them, and the git history of his tree seems to
 agree.

(*) Thanks for the clarification, Björn. What made me stumbling was the 
different orginators, while Jeff isn't known with catching attention by 
assimilating other peoples contributions. 

 Probably the other commit is similar.

 Björn

 [1] http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg11957.html

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

arcmsr changelog differs from diffs

[Hans-Peter Jansen]

Hi Jeff,

while browsing through Linus' current check ins, I stumbled upon:

[SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:

--8<--
488a5c8a9a3b67ae117784cd0d73bef53a73d57d
 drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c 
b/drivers/scsi/arcmsr/arcmsr_hba.c
index 7832a10..f4d2d52 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -422,7 +422,7 @@ static int arcmsr_probe(struct pci_dev *pdev,
goto out_release_regions;
 
error = request_irq(pdev->irq, arcmsr_do_interrupt,
-   IRQF_SHARED, "arcmsr", acb);
+   IRQF_SHARED, "arcmsr", acb);
if (error)
goto out_free_ccb_pool;
 
-->8--

and: [SCSI] arcmsr: Fix hardware wait loops

--8<--
24430458bb924e371ff894e26bfa9f73707f53fb
 drivers/scsi/arcmsr/arcmsr_hba.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c 
b/drivers/scsi/arcmsr/arcmsr_hba.c
index 50e1310..7832a10 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2092,8 +2092,10 @@ static void arcmsr_iop_reset(struct 
AdapterControlBlock *acb)
if (atomic_read(>ccboutstandingcount) != 0) {
/* talk to iop 331 outstanding command aborted */
arcmsr_abort_allcmd(acb);
+
/* wait for 3 sec for all command aborted*/
ssleep(3);
+
/* disable all outbound interrupt */
intmask_org = arcmsr_disable_outbound_ints(acb);
/* clear all outbound posted Q */
-->8--

where both changelogs differ significantly from the actual diffs, which both 
are simple WS fixups and nothing else. Does qgit fools me here, or is 
anything else wrong on my side?

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

arcmsr changelog differs from diffs

[Hans-Peter Jansen]

Hi Jeff,

while browsing through Linus' current check ins, I stumbled upon:

[SCSI] arcmsr: irq handler fixes, cleanups, micro-opts:

--8--
488a5c8a9a3b67ae117784cd0d73bef53a73d57d
 drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c 
b/drivers/scsi/arcmsr/arcmsr_hba.c
index 7832a10..f4d2d52 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -422,7 +422,7 @@ static int arcmsr_probe(struct pci_dev *pdev,
goto out_release_regions;
 
error = request_irq(pdev-irq, arcmsr_do_interrupt,
-   IRQF_SHARED, arcmsr, acb);
+   IRQF_SHARED, arcmsr, acb);
if (error)
goto out_free_ccb_pool;
 
--8--

and: [SCSI] arcmsr: Fix hardware wait loops

--8--
24430458bb924e371ff894e26bfa9f73707f53fb
 drivers/scsi/arcmsr/arcmsr_hba.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c 
b/drivers/scsi/arcmsr/arcmsr_hba.c
index 50e1310..7832a10 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2092,8 +2092,10 @@ static void arcmsr_iop_reset(struct 
AdapterControlBlock *acb)
if (atomic_read(acb-ccboutstandingcount) != 0) {
/* talk to iop 331 outstanding command aborted */
arcmsr_abort_allcmd(acb);
+
/* wait for 3 sec for all command aborted*/
ssleep(3);
+
/* disable all outbound interrupt */
intmask_org = arcmsr_disable_outbound_ints(acb);
/* clear all outbound posted Q */
--8--

where both changelogs differ significantly from the actual diffs, which both 
are simple WS fixups and nothing else. Does qgit fools me here, or is 
anything else wrong on my side?

Pete
-
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: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES

[Hans-Peter Jansen]

Am Samstag, 6. Oktober 2007 10:29 schrieb Hans-Peter Jansen:
> Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
> >  Hey there,
> >
> > I've seen the changes you made in commit b6a2fea39318 and I guess they
> > might be responsible for my xargs breakage...
> >
> > In the kernel source tree, if I run a stupid find | xargs ls, I now get
> > this:
> > xargs: ls: Argument list too long
>
> Have you tried to remove xarg from the equation above, just in case that
> it stumbles upon the elemination of the reason for its existence in the
> first place..

Sorry guys, filtering by "linus" in kmail suppressed the solution messages 
in this thread.

Pete
-
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: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES

[Hans-Peter Jansen]

Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
>  Hey there,
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long

Have you tried to remove xarg from the equation above, just in case that it 
stumbles upon the elemination of the reason for its existence in the first 
place..

Pete
-
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: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES

[Hans-Peter Jansen]

Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
  Hey there,

 I've seen the changes you made in commit b6a2fea39318 and I guess they
 might be responsible for my xargs breakage...

 In the kernel source tree, if I run a stupid find | xargs ls, I now get
 this:
 xargs: ls: Argument list too long

Have you tried to remove xarg from the equation above, just in case that it 
stumbles upon the elemination of the reason for its existence in the first 
place..

Pete
-
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: [BUG] Linux 2.6.23-rc9 and MAX_ARG_PAGES

[Hans-Peter Jansen]

Am Samstag, 6. Oktober 2007 10:29 schrieb Hans-Peter Jansen:
 Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
   Hey there,
 
  I've seen the changes you made in commit b6a2fea39318 and I guess they
  might be responsible for my xargs breakage...
 
  In the kernel source tree, if I run a stupid find | xargs ls, I now get
  this:
  xargs: ls: Argument list too long

 Have you tried to remove xarg from the equation above, just in case that
 it stumbles upon the elemination of the reason for its existence in the
 first place..

Sorry guys, filtering by linus in kmail suppressed the solution messages 
in this thread.

Pete
-
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: [RFC 12/26] ext2 white-out support

[Hans-Peter Jansen]

Am Dienstag, 31. Juli 2007 19:00 schrieb Jan Blunck:
> On Tue, Jul 31, Josef Sipek wrote:
> > On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
> > > Introduce white-out support to ext2.
> >
> > I think storing whiteouts on the branches is wrong. It creates all sort
> > of nasty cases when people actually try to use unioning. Imagine a
> > (no-so unlikely) scenario where you have 2 unions, and they share a
> > branch. If you create a whiteout in one union on that shared branch,
> > the whiteout magically affects the other union as well! Whiteouts are a
> > union-level construct, and therefore storing them at the branch level
> > is wrong.
>
> So you think that just because you mounted the filesystem somewhere else
> it should look different? This is what sharing is all about. If you share
> a filesystem you also share the removal of objects.

No. At least I don't. 

Usage case: I heavily depend on using union mounts in diskless nfs setups, 
since it drops the amount of administration of many systems _near_ one. It 
boils down on installing the distribution of your choice in a directory, 
union mount it ro, overlayed with a node private one (doing this in initrd 
on the client for several reasons), add a little boot and automatic setup 
machinery and be done. Since all changes are persistant, any system can be 
set up individually, and still mostly only one tree is needed to keep up to 
date.. Being in production in an office environment since two years without 
major hassle (*).

This setup is likely to be useful for virtualization needs, too, but side 
effects via the base directory from one node to another would render this 
setup void.

Cheers,
  Pete

*) The amount of administration work of any (necessary, unfortunately) 
VMware XP instance running on top of those diskless clients excels that of 
all diskless clients by an order of magnitude. 
-
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: [RFC 12/26] ext2 white-out support

[Hans-Peter Jansen]

Am Dienstag, 31. Juli 2007 19:00 schrieb Jan Blunck:
 On Tue, Jul 31, Josef Sipek wrote:
  On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
   Introduce white-out support to ext2.
 
  I think storing whiteouts on the branches is wrong. It creates all sort
  of nasty cases when people actually try to use unioning. Imagine a
  (no-so unlikely) scenario where you have 2 unions, and they share a
  branch. If you create a whiteout in one union on that shared branch,
  the whiteout magically affects the other union as well! Whiteouts are a
  union-level construct, and therefore storing them at the branch level
  is wrong.

 So you think that just because you mounted the filesystem somewhere else
 it should look different? This is what sharing is all about. If you share
 a filesystem you also share the removal of objects.

No. At least I don't. 

Usage case: I heavily depend on using union mounts in diskless nfs setups, 
since it drops the amount of administration of many systems _near_ one. It 
boils down on installing the distribution of your choice in a directory, 
union mount it ro, overlayed with a node private one (doing this in initrd 
on the client for several reasons), add a little boot and automatic setup 
machinery and be done. Since all changes are persistant, any system can be 
set up individually, and still mostly only one tree is needed to keep up to 
date.. Being in production in an office environment since two years without 
major hassle (*).

This setup is likely to be useful for virtualization needs, too, but side 
effects via the base directory from one node to another would render this 
setup void.

Cheers,
  Pete

*) The amount of administration work of any (necessary, unfortunately) 
VMware XP instance running on top of those diskless clients excels that of 
all diskless clients by an order of magnitude. 
-
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: Adding subroot information to /proc/mounts, or obtaining that through other means

[Hans-Peter Jansen]

Am Donnerstag, 21. Juni 2007 00:46 schrieb H. Peter Anvin:
> Dr. David Alan Gilbert wrote:
> > What happens with the (sick) case of spaces in directory names?
> > Also is it really nicely defined that there is no way to put a space
> > in an option in any of the filesystems?   I suppose someone
> > particularly sick could have a device node in a directory with a space
> > in it.  It would be nice if new formats for this are being defined
> > to make it cover everything.
>
> That's already handled just fine:
>
> bash-3.1$ mkdir /tmp/'Jag är: \
> en liten mask'
> bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
> en liten mask'/
> bash-3.1$ tail -1 /proc/mounts
> none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
> bash-3.1$

Hmm, and what about the even sicker case: /tmp/\040, parse as /tmp/\\040?
Do userspace cope with this?

Happy parsingly y'rs,
  Pete
-
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: Adding subroot information to /proc/mounts, or obtaining that through other means

[Hans-Peter Jansen]

Am Donnerstag, 21. Juni 2007 00:46 schrieb H. Peter Anvin:
 Dr. David Alan Gilbert wrote:
  What happens with the (sick) case of spaces in directory names?
  Also is it really nicely defined that there is no way to put a space
  in an option in any of the filesystems?   I suppose someone
  particularly sick could have a device node in a directory with a space
  in it.  It would be nice if new formats for this are being defined
  to make it cover everything.

 That's already handled just fine:

 bash-3.1$ mkdir /tmp/'Jag är: \
 en liten mask'
 bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
 en liten mask'/
 bash-3.1$ tail -1 /proc/mounts
 none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
 bash-3.1$

Hmm, and what about the even sicker case: /tmp/\040, parse as /tmp/\\040?
Do userspace cope with this?

Happy parsingly y'rs,
  Pete
-
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] XFS: Replace remaining memclear_highpage_flush() with zero_user_page().

[Hans-Peter Jansen]

Am Montag, 18. Juni 2007 20:43 schrieb Christoph Hellwig:
> On Mon, Jun 18, 2007 at 11:59:30AM -0400, Robert P. J. Day wrote:
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

FYI, this patch got attributed to Christoph in Linus' tree with commit 
700716c8468d95ec6d03566a4e4fb576c3223cbc..

Cheers,
  hp


> > ---
> >
> >   this appears to be the final occurrence of that deprecated call in
> > the entire tree which suggests that, if you're not concerned about
> > out-of-tree modules, that definition could also be removed from
> > include/linux/highmem.h:
> >
> > static inline void __deprecated memclear_highpage_flush(struct page
> > *page, unsigned int offset, unsigned int size) {
> > zero_user_page(page, offset, size, KM_USER0);
> > }
>
> Andrew, please send this and the memclear_highpage_flush removal to Linus
> for 2.6.22-rc.  The warning is really highly annoying and utterly
> pointless. -
> 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/
-
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] XFS: Replace remaining memclear_highpage_flush() with zero_user_page().

[Hans-Peter Jansen]

Am Montag, 18. Juni 2007 20:43 schrieb Christoph Hellwig:
 On Mon, Jun 18, 2007 at 11:59:30AM -0400, Robert P. J. Day wrote:
  Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]

FYI, this patch got attributed to Christoph in Linus' tree with commit 
700716c8468d95ec6d03566a4e4fb576c3223cbc..

Cheers,
  hp


  ---
 
this appears to be the final occurrence of that deprecated call in
  the entire tree which suggests that, if you're not concerned about
  out-of-tree modules, that definition could also be removed from
  include/linux/highmem.h:
 
  static inline void __deprecated memclear_highpage_flush(struct page
  *page, unsigned int offset, unsigned int size) {
  zero_user_page(page, offset, size, KM_USER0);
  }

 Andrew, please send this and the memclear_highpage_flush removal to Linus
 for 2.6.22-rc.  The warning is really highly annoying and utterly
 pointless. -
 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/
-
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: irq nobody cared issue on 2.6.2x

[Hans-Peter Jansen]

Am Mittwoch, 7. März 2007 20:48 schrieb Mws:
> hi all,
>
> i just moved my win tv dvb-s card (PCI) from my old to my actual pc.
>
> its an ASUS M2N32 WS Professional AMD64 X2 Board equiped with
> the nvidia nForce 590 SLI MCP chipset.
>
> in the past, i had to use the noapic kernel cmdline param to get linux
> booting and working properly.
>
> iirc versions >=2.6.18 of the kernel fixed all of my previous problems,
> thus i am not using noapic since then.

Hmm, I'm using the same board here since two weeks. openSUSE 10.2 (i586, 
kernel 2.6.18.{2,8}) didn't installed properly even with noapic (problems 
with eth device while installing from nfs server :-(, temporarily work 
arounded with an e1000). I found a BIOS update necessary for proper apic 
operation. No problems since then, but not using a dvb card in there 
either, since my vdr is a seperate system ;-)..

Cheers,
   Pete
-
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: irq nobody cared issue on 2.6.2x

[Hans-Peter Jansen]

Am Mittwoch, 7. März 2007 20:48 schrieb Mws:
 hi all,

 i just moved my win tv dvb-s card (PCI) from my old to my actual pc.

 its an ASUS M2N32 WS Professional AMD64 X2 Board equiped with
 the nvidia nForce 590 SLI MCP chipset.

 in the past, i had to use the noapic kernel cmdline param to get linux
 booting and working properly.

 iirc versions =2.6.18 of the kernel fixed all of my previous problems,
 thus i am not using noapic since then.

Hmm, I'm using the same board here since two weeks. openSUSE 10.2 (i586, 
kernel 2.6.18.{2,8}) didn't installed properly even with noapic (problems 
with eth device while installing from nfs server :-(, temporarily work 
arounded with an e1000). I found a BIOS update necessary for proper apic 
operation. No problems since then, but not using a dvb card in there 
either, since my vdr is a seperate system ;-)..

Cheers,
   Pete
-
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: prioritize PCI traffic ?

[Hans-Peter Jansen]

Am Montag, 15. Januar 2007 15:53 schrieb Vaidyanathan Srinivasan:
>
> 33Mhz 32-bit PCI bus on typical PC can do around 100MB/sec... 

Substract roughly n * 5MB for VIA chipsets, where n is the age (1 <= n <= 
4), and even more for SIS, ATI..

Pete
-
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: prioritize PCI traffic ?

[Hans-Peter Jansen]

Am Montag, 15. Januar 2007 15:53 schrieb Vaidyanathan Srinivasan:

 33Mhz 32-bit PCI bus on typical PC can do around 100MB/sec... 

Substract roughly n * 5MB for VIA chipsets, where n is the age (1 = n = 
4), and even more for SIS, ATI..

Pete
-
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: Mounting NFS root FS

[Hans-Peter Jansen]

Am Montag, 4. Dezember 2006 12:51 schrieb Janne Karhunen:
> On 12/2/06, William Estrada <[EMAIL PROTECTED]> wrote:
> > Hi guys,
> >
> >   I have been trying to make FC5's kernel do a boot
> > with an NFS root file system.  I see the support is in the
> > kernel(?).
>
> Is this really properly possible (with read/write access and
> locking in place)? AFAIK NFS client lock state data seems
> to require persistent storage .. ?

Out of curiosity: what's the rational of mounting multiple diskless nodes on 
one rw nfs root filesystem [with locking in place]? 

In my experience, this results in a big mess. I depend heavily on diskless 
setups, where I spent significant time to provide sharing as much data as 
possible between the clients _without_ further interference. The best setup 
I found to get there is using unionfs (which still has issues, mostly due 
to missing/broken mmap support).

Pete
-
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: Mounting NFS root FS

[Hans-Peter Jansen]

Am Montag, 4. Dezember 2006 12:51 schrieb Janne Karhunen:
 On 12/2/06, William Estrada [EMAIL PROTECTED] wrote:
  Hi guys,
 
I have been trying to make FC5's kernel do a boot
  with an NFS root file system.  I see the support is in the
  kernel(?).

 Is this really properly possible (with read/write access and
 locking in place)? AFAIK NFS client lock state data seems
 to require persistent storage .. ?

Out of curiosity: what's the rational of mounting multiple diskless nodes on 
one rw nfs root filesystem [with locking in place]? 

In my experience, this results in a big mess. I depend heavily on diskless 
setups, where I spent significant time to provide sharing as much data as 
possible between the clients _without_ further interference. The best setup 
I found to get there is using unionfs (which still has issues, mostly due 
to missing/broken mmap support).

Pete
-
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] kernel spams syslog every 10 sec with w1 debug

[Hans-Peter Jansen]

Am Freitag, 12. August 2005 18:00 schrieb Dave Jones:
> On Fri, Aug 12, 2005 at 05:38:37PM +0200, Andi Kleen wrote:
>  > Olaf Hering <[EMAIL PROTECTED]> writes:
>  > > Bug 104020 - kernel spams syslog every 10 sec with: w1_driver
>  > > w1_bus_master1: No devices present on the wire.
>  > >
>  > > After installing 10.0 B1, I found this in my syslog:
>  > > Aug 10 23:40:06 linux kernel: w1_driver w1_bus_master1: No
>  > > devices present on the wire. Aug 10 23:40:16 linux kernel:
>  > > w1_driver w1_bus_master1: No devices present on the wire.
>  >
>  > More interesting is why this thing is running at all.
>  > It shouldn't.
>
> Doesnt that get loaded if there's a Matrox card present ?
> (I am completely guessing here, so could be way off base).

Guess matched! Most of my systems run these (should I say unfortunately 
8|)

And sorry for the late reply. I didn't notice, that my report leaked 
into lkml.. ;-)

Pete
-
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] kernel spams syslog every 10 sec with w1 debug

[Hans-Peter Jansen]

Am Freitag, 12. August 2005 18:00 schrieb Dave Jones:
 On Fri, Aug 12, 2005 at 05:38:37PM +0200, Andi Kleen wrote:
   Olaf Hering [EMAIL PROTECTED] writes:
Bug 104020 - kernel spams syslog every 10 sec with: w1_driver
w1_bus_master1: No devices present on the wire.
   
After installing 10.0 B1, I found this in my syslog:
Aug 10 23:40:06 linux kernel: w1_driver w1_bus_master1: No
devices present on the wire. Aug 10 23:40:16 linux kernel:
w1_driver w1_bus_master1: No devices present on the wire.
  
   More interesting is why this thing is running at all.
   It shouldn't.

 Doesnt that get loaded if there's a Matrox card present ?
 (I am completely guessing here, so could be way off base).

Guess matched! Most of my systems run these (should I say unfortunately 
8|)

And sorry for the late reply. I didn't notice, that my report leaked 
into lkml.. ;-)

Pete
-
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] ppc64: Implement a vDSO and use it for signal trampoline #3

[Hans-Peter Jansen]

Hi Ben,

are you copyrighting under a new pseudonym? E.g.:

On Thursday 10 February 2005 03:32, Benjamin Herrenschmidt wrote:
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-work/arch/ppc64/kernel/vdso32/sigtramp.S2005-02-02
> 13:28:01.0 +1100 @@ -0,0 +1,300 @@
> +/*
> + * Signal trampolines for 32 bits processes in a ppc64 kernel for
> + * use in the vDSO
> + *
> + * Copyright (C) 2004 Benjamin Herrenschmuidt
^
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-work/arch/ppc64/kernel/vdso32/datapage.S2005-02-02
> 13:28:01.0 +1100 @@ -0,0 +1,68 @@
> +/*
> + * Access to the shared data page by the vDSO & syscall map
> + *
> + * Copyright (C) 2004 Benjamin Herrenschmuidt

Who's that guy?

Pete

-
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] ppc64: Implement a vDSO and use it for signal trampoline #3

[Hans-Peter Jansen]

Hi Ben,

are you copyrighting under a new pseudonym? E.g.:

On Thursday 10 February 2005 03:32, Benjamin Herrenschmidt wrote:
 ===
 --- /dev/null 1970-01-01 00:00:00.0 +
 +++ linux-work/arch/ppc64/kernel/vdso32/sigtramp.S2005-02-02
 13:28:01.0 +1100 @@ -0,0 +1,300 @@
 +/*
 + * Signal trampolines for 32 bits processes in a ppc64 kernel for
 + * use in the vDSO
 + *
 + * Copyright (C) 2004 Benjamin Herrenschmuidt
^
 --- /dev/null 1970-01-01 00:00:00.0 +
 +++ linux-work/arch/ppc64/kernel/vdso32/datapage.S2005-02-02
 13:28:01.0 +1100 @@ -0,0 +1,68 @@
 +/*
 + * Access to the shared data page by the vDSO  syscall map
 + *
 + * Copyright (C) 2004 Benjamin Herrenschmuidt

Who's that guy?

Pete

-
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] Configure MTU via kernel DHCP

[Hans-Peter Jansen]

On Friday 04 February 2005 19:22, Richard A Nelson wrote:
>
> What will this code do at the (increasingly common) misconfigured
> sites - many places (hotels, airports, etc) return a MTU of 64...
> to which the DHCP3 client faithfully attempts to set, only to
> receive:
>   SIOCSIFMTU: Invalid argument

Well, the ip auto configuration is mainly intended for diskless 
setups, not something, one will use in an uncontrolled environment.
I doubt, it will behave different, as well as usual distribution 
kernels will never enable this by default..

Pete

-
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] Configure MTU via kernel DHCP

[Hans-Peter Jansen]

Hi Shane,

On Thursday 03 February 2005 05:47, Shane Hathaway wrote:
> The attached patch enhances the kernel's DHCP client support (in
> net/ipv4/ipconfig.c) to set the interface MTU if provided by the
> DHCP server. Without this patch, it's difficult to netboot on a
> network that uses jumbo frames.  The patch is based on 2.6.10, but
> I'll update it to the latest testing kernel if that would expedite
> its inclusion in the kernel.

Well, I've been there before, and asked for exact the same back in 
June 2003, but had much less luck, nobody of kernel fame even 
responded:
http://marc.theaimsgroup.com/?l=linux-kernel=105624464918574=4

Only Ken Yap of etherboot fame told me:
> I have a feeling you will not get much sympathy for 2.[56] because
> there ipconfig in the kernel is deprecated in favour of userspace
> config from the initrd.

Well that's life. 

For what is worth it, I ported my patch to current 2.6, which raised 
some comments compared to yours:

 - Is it really necessary to protect the dev_set_mtu call, since it is
   just setting up the device?
 - I prefer to call dev_set_mtu only, if a change mtu request is
   sent.. 
 - Are you sure, you got the endianess right? 

Here's the "cost": ipconfig.o without my patch on x86:

  3 .init.data005a      0220  2**2
  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .rodata.str1.1 01a2      027a  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rodata.str1.4 03ad      041c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .init.text1a45      07d0  2**4
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

With patch:

  3 .init.data005e      0220  2**2
  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .rodata.str1.1 01ab      027e  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rodata.str1.4 03e5      042c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .init.text1ab5      0820  2**4
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

Difference: 181 Bytes (padding ignored)

The whole module takes about 9K, compared to dhcp in initrd, which 
takes a few hundred K! Hmm.

> Incidentally, ipconfig.c doesn't appear to do enough bounds
> checking on byte 1 of DHCP/BOOTP extension fields (the length
> field).  It looks like a malicious DHCP server could mess with
> kernel memory that way.  I could try to fix the hole, but maybe
> someone more experienced with this code would like to verify
> there's a problem first.

That's an interesting question. Please keep me informed on any new 
perceptions in this respect.

May the linux gods indulge on this topic one day or remove the 
ipconfig module completely.

--- linux-2.6/net/ipv4/ipconfig.c.orig  2005-02-04 15:59:42.430518242 +0100
+++ linux-2.6/net/ipv4/ipconfig.c   2005-02-04 17:07:14.526384702 +0100
@@ -29,6 +29,10 @@
  *
  *  Multiple Nameservers in /proc/net/pnp
  *  --  Josef Siemes <[EMAIL PROTECTED]>, Aug 2002
+ *
+ *  Support for MTU selection via DHCP
+ *  -- Hans-Peter Jansen <[EMAIL PROTECTED]>, June 2003
+ *  redone for 2.6 in February 2005
  */
 
 #include 
@@ -151,6 +155,9 @@
 /* Protocols supported by available interfaces */
 static int ic_proto_have_if __initdata = 0;
 
+/* MTU of device (if requested) */
+static int ic_dev_mtu __initdata = 0;
+
 #ifdef IPCONFIG_DYNAMIC
 static DEFINE_SPINLOCK(ic_recv_lock);
 static volatile int ic_got_reply __initdata = 0;/* Proto(s) that replied */
@@ -322,6 +329,12 @@
printk(KERN_ERR "IP-Config: Unable to set interface broadcast 
address (%d).\n", err);
return -1;
}
+   if (ic_dev_mtu) {
+   if ((err = dev_set_mtu(ic_dev, ic_dev_mtu)) < 0)
+   printk(KERN_ERR "IP-Config: Unable to set interface mtu 
to %d (%d).\n", 
+   ic_dev_mtu, err);
+   /* Don't error out because set mtu failure, just notice 
the operator */
+   }
return 0;
 }
 
@@ -609,6 +622,7 @@
12, /* Host name */
15, /* Domain name */
17, /* Boot path */
+   26, /* MTU */
40, /* NIS domain name */
};
 
@@ -812,6 +826,9 @@
if (!root_server_path[0])
ic_bootp_string(root_server_path, ext+1, *ext, 
sizeof(root_server_path));
break;
+   case 26:/* MTU */
+   ic_dev_mtu = ntohs(*(u16 *)(ext+1));
+   break;
   

Re: [PATCH] Configure MTU via kernel DHCP

[Hans-Peter Jansen]

Hi Shane,

On Thursday 03 February 2005 05:47, Shane Hathaway wrote:
 The attached patch enhances the kernel's DHCP client support (in
 net/ipv4/ipconfig.c) to set the interface MTU if provided by the
 DHCP server. Without this patch, it's difficult to netboot on a
 network that uses jumbo frames.  The patch is based on 2.6.10, but
 I'll update it to the latest testing kernel if that would expedite
 its inclusion in the kernel.

Well, I've been there before, and asked for exact the same back in 
June 2003, but had much less luck, nobody of kernel fame even 
responded:
http://marc.theaimsgroup.com/?l=linux-kernelm=105624464918574w=4

Only Ken Yap of etherboot fame told me:
 I have a feeling you will not get much sympathy for 2.[56] because
 there ipconfig in the kernel is deprecated in favour of userspace
 config from the initrd.

Well that's life. 

For what is worth it, I ported my patch to current 2.6, which raised 
some comments compared to yours:

 - Is it really necessary to protect the dev_set_mtu call, since it is
   just setting up the device?
 - I prefer to call dev_set_mtu only, if a change mtu request is
   sent.. 
 - Are you sure, you got the endianess right? 

Here's the cost: ipconfig.o without my patch on x86:

  3 .init.data005a      0220  2**2
  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .rodata.str1.1 01a2      027a  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rodata.str1.4 03ad      041c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .init.text1a45      07d0  2**4
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

With patch:

  3 .init.data005e      0220  2**2
  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .rodata.str1.1 01ab      027e  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rodata.str1.4 03e5      042c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .init.text1ab5      0820  2**4
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE

Difference: 181 Bytes (padding ignored)

The whole module takes about 9K, compared to dhcp in initrd, which 
takes a few hundred K! Hmm.

 Incidentally, ipconfig.c doesn't appear to do enough bounds
 checking on byte 1 of DHCP/BOOTP extension fields (the length
 field).  It looks like a malicious DHCP server could mess with
 kernel memory that way.  I could try to fix the hole, but maybe
 someone more experienced with this code would like to verify
 there's a problem first.

That's an interesting question. Please keep me informed on any new 
perceptions in this respect.

May the linux gods indulge on this topic one day or remove the 
ipconfig module completely.

--- linux-2.6/net/ipv4/ipconfig.c.orig  2005-02-04 15:59:42.430518242 +0100
+++ linux-2.6/net/ipv4/ipconfig.c   2005-02-04 17:07:14.526384702 +0100
@@ -29,6 +29,10 @@
  *
  *  Multiple Nameservers in /proc/net/pnp
  *  --  Josef Siemes [EMAIL PROTECTED], Aug 2002
+ *
+ *  Support for MTU selection via DHCP
+ *  -- Hans-Peter Jansen [EMAIL PROTECTED], June 2003
+ *  redone for 2.6 in February 2005
  */
 
 #include linux/config.h
@@ -151,6 +155,9 @@
 /* Protocols supported by available interfaces */
 static int ic_proto_have_if __initdata = 0;
 
+/* MTU of device (if requested) */
+static int ic_dev_mtu __initdata = 0;
+
 #ifdef IPCONFIG_DYNAMIC
 static DEFINE_SPINLOCK(ic_recv_lock);
 static volatile int ic_got_reply __initdata = 0;/* Proto(s) that replied */
@@ -322,6 +329,12 @@
printk(KERN_ERR IP-Config: Unable to set interface broadcast 
address (%d).\n, err);
return -1;
}
+   if (ic_dev_mtu) {
+   if ((err = dev_set_mtu(ic_dev, ic_dev_mtu))  0)
+   printk(KERN_ERR IP-Config: Unable to set interface mtu 
to %d (%d).\n, 
+   ic_dev_mtu, err);
+   /* Don't error out because set mtu failure, just notice 
the operator */
+   }
return 0;
 }
 
@@ -609,6 +622,7 @@
12, /* Host name */
15, /* Domain name */
17, /* Boot path */
+   26, /* MTU */
40, /* NIS domain name */
};
 
@@ -812,6 +826,9 @@
if (!root_server_path[0])
ic_bootp_string(root_server_path, ext+1, *ext, 
sizeof(root_server_path));
break;
+   case 26:/* MTU */
+   ic_dev_mtu = ntohs(*(u16 *)(ext+1));
+   break;
case 40:/* NIS Domain name (_not_ DNS) */
ic_bootp_string

Re: [PATCH] Configure MTU via kernel DHCP

[Hans-Peter Jansen]

On Friday 04 February 2005 19:22, Richard A Nelson wrote:

 What will this code do at the (increasingly common) misconfigured
 sites - many places (hotels, airports, etc) return a MTU of 64...
 to which the DHCP3 client faithfully attempts to set, only to
 receive:
   SIOCSIFMTU: Invalid argument

Well, the ip auto configuration is mainly intended for diskless 
setups, not something, one will use in an uncontrolled environment.
I doubt, it will behave different, as well as usual distribution 
kernels will never enable this by default..

Pete

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