Re: BUG: "do_IRQ: 0.39 No irq handler for vector" from a 16550 port

[Holger Schurig]

I said that kernel 4.9 doesn't show the issue. The same was for later
kernels up to 4.13.

I had a compilation issue with 4.14 (which I later solved, something
unrelated with tools/objcopy when compiling for a different
architecture), so I did a git bisect between v4.13 and v4.15. This is
the outcome:

$ git bisect log
# bad: [d8a5b80568a9cb66810e75b182018e9edb68e8ff] Linux 4.15
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect start 'v4.15' 'v4.13'
# good: [425a08c67317acee103b3ad58f57c762e8834faf] mlxsw: spectrum_router: 
Prepare for large adjacency groups
git bisect good 425a08c67317acee103b3ad58f57c762e8834faf
# bad: [e60e1ee60630cafef5e430c2ae364877e061d980] Merge tag 'drm-for-v4.15' of 
git://people.freedesktop.org/~airlied/linux
git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980
# bad: [4008e6a9bcee2f3b61bb11951de0fb0ed764cb91] Merge branch 'i2c/for-4.15' 
of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect bad 4008e6a9bcee2f3b61bb11951de0fb0ed764cb91
# bad: [3c073991eb417b6f785ddc6afbbdc369eb84aa6a] Merge tag 'devprop-4.15-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 3c073991eb417b6f785ddc6afbbdc369eb84aa6a
# good: [2101dd64b304b034862f5ca40877c41b7ccb9c5e] Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
git bisect good 2101dd64b304b034862f5ca40877c41b7ccb9c5e
# good: [d6ec9d9a4def52a5094237564eaf6f6979fd7a27] Merge branch 
'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d6ec9d9a4def52a5094237564eaf6f6979fd7a27
# good: [7d58e1c9059eefe0066c5acf2ffa582f6f0180e3] Merge branch 
'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 7d58e1c9059eefe0066c5acf2ffa582f6f0180e3
# good: [990a848d537e4da966907c8ccec95bc568f2911c] Merge branches 'pm-devfreq' 
and 'pm-tools'
git bisect good 990a848d537e4da966907c8ccec95bc568f2911c
# bad: [25e960efc63852b84d1c3739aef586285b177395] PCI/MSI: Set 
MSI_FLAG_MUST_REACTIVATE in core code
git bisect bad 25e960efc63852b84d1c3739aef586285b177395
# skip: [029c6e1c9df776fe1b2ba756a28fb65e9f9e9f69] x86/vector: Store the single 
CPU targets in apic data
git bisect skip 029c6e1c9df776fe1b2ba756a28fb65e9f9e9f69

- no network
- no USB keyboard
- therefore "git bisect skip"

# bad: [d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c] x86/vector: Respect affinity 
mask in irq descriptor
git bisect bad d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c
# good: [ef9e56d894eab99a33a06b96ba8057afa67d3702] x86/ioapic: Remove obsolete 
post hotplug update
git bisect good ef9e56d894eab99a33a06b96ba8057afa67d3702
# good: [8d1e3dca7de6e8513872799a748a1d47d8dce60d] x86/vector: Add tracepoints 
for vector management
git bisect good 8d1e3dca7de6e8513872799a748a1d47d8dce60d
# good: [5ba204a1817ba95a7b24dbe8ef2c7ddd4cea886e] iommu/amd: Reevaluate vector 
configuration on activate()
git bisect good 5ba204a1817ba95a7b24dbe8ef2c7ddd4cea886e
# good: [4900be83602b6be07366d3e69f756c1959f4169a] x86/vector/msi: Switch to 
global reservation mode
git bisect good 4900be83602b6be07366d3e69f756c1959f4169a
# bad: [2cffad7bad83157f89332872015f4305d2ac09ac] x86/irq: Simplify hotplug 
vector accounting
git bisect bad 2cffad7bad83157f89332872015f4305d2ac09ac
# bad: [464d12309e1b5829597793db551ae8ecaecf4036] x86/vector: Switch IOAPIC to 
global reservation mode
git bisect bad 464d12309e1b5829597793db551ae8ecaecf4036
# first bad commit: [464d12309e1b5829597793db551ae8ecaecf4036] x86/vector: 
Switch IOAPIC to global reservation mode




Greetings,
Holger

Re: BUG: "do_IRQ: 0.39 No irq handler for vector" from a 16550 port

[Holger Schurig]

I said that kernel 4.9 doesn't show the issue. The same was for later
kernels up to 4.13.

I had a compilation issue with 4.14 (which I later solved, something
unrelated with tools/objcopy when compiling for a different
architecture), so I did a git bisect between v4.13 and v4.15. This is
the outcome:

$ git bisect log
# bad: [d8a5b80568a9cb66810e75b182018e9edb68e8ff] Linux 4.15
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect start 'v4.15' 'v4.13'
# good: [425a08c67317acee103b3ad58f57c762e8834faf] mlxsw: spectrum_router: 
Prepare for large adjacency groups
git bisect good 425a08c67317acee103b3ad58f57c762e8834faf
# bad: [e60e1ee60630cafef5e430c2ae364877e061d980] Merge tag 'drm-for-v4.15' of 
git://people.freedesktop.org/~airlied/linux
git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980
# bad: [4008e6a9bcee2f3b61bb11951de0fb0ed764cb91] Merge branch 'i2c/for-4.15' 
of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect bad 4008e6a9bcee2f3b61bb11951de0fb0ed764cb91
# bad: [3c073991eb417b6f785ddc6afbbdc369eb84aa6a] Merge tag 'devprop-4.15-rc1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 3c073991eb417b6f785ddc6afbbdc369eb84aa6a
# good: [2101dd64b304b034862f5ca40877c41b7ccb9c5e] Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
git bisect good 2101dd64b304b034862f5ca40877c41b7ccb9c5e
# good: [d6ec9d9a4def52a5094237564eaf6f6979fd7a27] Merge branch 
'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good d6ec9d9a4def52a5094237564eaf6f6979fd7a27
# good: [7d58e1c9059eefe0066c5acf2ffa582f6f0180e3] Merge branch 
'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 7d58e1c9059eefe0066c5acf2ffa582f6f0180e3
# good: [990a848d537e4da966907c8ccec95bc568f2911c] Merge branches 'pm-devfreq' 
and 'pm-tools'
git bisect good 990a848d537e4da966907c8ccec95bc568f2911c
# bad: [25e960efc63852b84d1c3739aef586285b177395] PCI/MSI: Set 
MSI_FLAG_MUST_REACTIVATE in core code
git bisect bad 25e960efc63852b84d1c3739aef586285b177395
# skip: [029c6e1c9df776fe1b2ba756a28fb65e9f9e9f69] x86/vector: Store the single 
CPU targets in apic data
git bisect skip 029c6e1c9df776fe1b2ba756a28fb65e9f9e9f69

- no network
- no USB keyboard
- therefore "git bisect skip"

# bad: [d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c] x86/vector: Respect affinity 
mask in irq descriptor
git bisect bad d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c
# good: [ef9e56d894eab99a33a06b96ba8057afa67d3702] x86/ioapic: Remove obsolete 
post hotplug update
git bisect good ef9e56d894eab99a33a06b96ba8057afa67d3702
# good: [8d1e3dca7de6e8513872799a748a1d47d8dce60d] x86/vector: Add tracepoints 
for vector management
git bisect good 8d1e3dca7de6e8513872799a748a1d47d8dce60d
# good: [5ba204a1817ba95a7b24dbe8ef2c7ddd4cea886e] iommu/amd: Reevaluate vector 
configuration on activate()
git bisect good 5ba204a1817ba95a7b24dbe8ef2c7ddd4cea886e
# good: [4900be83602b6be07366d3e69f756c1959f4169a] x86/vector/msi: Switch to 
global reservation mode
git bisect good 4900be83602b6be07366d3e69f756c1959f4169a
# bad: [2cffad7bad83157f89332872015f4305d2ac09ac] x86/irq: Simplify hotplug 
vector accounting
git bisect bad 2cffad7bad83157f89332872015f4305d2ac09ac
# bad: [464d12309e1b5829597793db551ae8ecaecf4036] x86/vector: Switch IOAPIC to 
global reservation mode
git bisect bad 464d12309e1b5829597793db551ae8ecaecf4036
# first bad commit: [464d12309e1b5829597793db551ae8ecaecf4036] x86/vector: 
Switch IOAPIC to global reservation mode




Greetings,
Holger

BUG: "do_IRQ: 0.39 No irq handler for vector" from a 16550 port

[Holger Schurig]

Hi all,

I have a weird bug on systems that uses Haswell Architecture and "real"
serial ports /dev/ttyS*.


Hardware: some embedded device with "Intel(R) Celeron(R) 2980U @
1.60GHz", I tried with microcode 0x23 and 0x24. Also on a HP Elite 840
G1". Both have Haswell architecture.

I can plug a different CPU module into the embedded device, then I have
an "Intel(R) Atom(TM) CPU N455 @ 1.66GHz", obviously no Haswell. With
identical kernel, I don't get the same error.



Kernel: happens with distro kernels (Debian, Ubuntu, Fedora). Common
factor seems that the kernels are >= 4.9.x. But also with upstream
stable kernels, I used 4.13.x, 4.14.x, 4.18.x, even with 4.18.16.




The embedded device also behaves strange (e.g. I had once MCEs with a
32bit kernel, which went away when using a 64bit kernel). We also
sometimes get an error in AUFS with the same timestamp as the
do_IRQ-message. I don't understand what AUFS has to do with hardware
interrupts. However, I don't want to concentrate on this yet, I think
that strange message in a mainland kernel in itself is worthwhile to be
tracked. If some interrupt get's haywire, there is certainly the chance
that some memory get's corrupted. Also, this might be something totally
different, because the HP Elite doesn't show this. Also, the MCE went
away after switching from 32bit kernel to 64bit kernel.

So, let's return to the better reproducible "do_IRQ: 0.39 No irq handler
for vector".


I'm happy that I found a way to reproduce it: the message triggers when
I close the serial port. printk's indicate that after the IER is
cleared, and even after synchronize_irq() in serial8250_do_shutdown()
the error happens.

Sometimes even a "stty 

BUG: "do_IRQ: 0.39 No irq handler for vector" from a 16550 port

[Holger Schurig]

Hi all,

I have a weird bug on systems that uses Haswell Architecture and "real"
serial ports /dev/ttyS*.


Hardware: some embedded device with "Intel(R) Celeron(R) 2980U @
1.60GHz", I tried with microcode 0x23 and 0x24. Also on a HP Elite 840
G1". Both have Haswell architecture.

I can plug a different CPU module into the embedded device, then I have
an "Intel(R) Atom(TM) CPU N455 @ 1.66GHz", obviously no Haswell. With
identical kernel, I don't get the same error.



Kernel: happens with distro kernels (Debian, Ubuntu, Fedora). Common
factor seems that the kernels are >= 4.9.x. But also with upstream
stable kernels, I used 4.13.x, 4.14.x, 4.18.x, even with 4.18.16.




The embedded device also behaves strange (e.g. I had once MCEs with a
32bit kernel, which went away when using a 64bit kernel). We also
sometimes get an error in AUFS with the same timestamp as the
do_IRQ-message. I don't understand what AUFS has to do with hardware
interrupts. However, I don't want to concentrate on this yet, I think
that strange message in a mainland kernel in itself is worthwhile to be
tracked. If some interrupt get's haywire, there is certainly the chance
that some memory get's corrupted. Also, this might be something totally
different, because the HP Elite doesn't show this. Also, the MCE went
away after switching from 32bit kernel to 64bit kernel.

So, let's return to the better reproducible "do_IRQ: 0.39 No irq handler
for vector".


I'm happy that I found a way to reproduce it: the message triggers when
I close the serial port. printk's indicate that after the IER is
cleared, and even after synchronize_irq() in serial8250_do_shutdown()
the error happens.

Sometimes even a "stty 

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Alexander Duyck  writes:
> Thanks for the data. It is actually useful. There are a few things
> that I see that seem to point to an obvious issue.

Any news on this?

A collegue of mine states (I have not checked this) that a kernel
4.9.0-6-686 from a Debian Live ISO (debian-live-9.4.0-i386-kde.iso)
didn't show this behavior, so we have some kind of regression perhaps?


Greetings,
Holger

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Alexander Duyck  writes:
> Thanks for the data. It is actually useful. There are a few things
> that I see that seem to point to an obvious issue.

Any news on this?

A collegue of mine states (I have not checked this) that a kernel
4.9.0-6-686 from a Debian Live ISO (debian-live-9.4.0-i386-kde.iso)
didn't show this behavior, so we have some kind of regression perhaps?


Greetings,
Holger

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi Alex,

> The first are the following 2 lines from your dump:
> Apr 26 10:42:49 kernel: igb :02:00.0 eth0: igb: eth0 NIC Link is
> Up 1000 Mbps Half Duplex, Flow Control: RX
> Apr 26 10:42:49 kernel: igb :02:00.0: EEE Disabled: unsupported at
> half duplex. Re-enable using ethtool when at full duplex.

Can it be the case that this is just a follow-up error?

In one of the mails from yesterday I showed you my patch to disable 1000
MB/s ... and still I had the link-always-down.

Similarly when I used a 10/100 MB/s switch only.

Both scenarios disabled 1000 MB/s, one more strictly than the other :-)

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi Alex,

> The first are the following 2 lines from your dump:
> Apr 26 10:42:49 kernel: igb :02:00.0 eth0: igb: eth0 NIC Link is
> Up 1000 Mbps Half Duplex, Flow Control: RX
> Apr 26 10:42:49 kernel: igb :02:00.0: EEE Disabled: unsupported at
> half duplex. Re-enable using ethtool when at full duplex.

Can it be the case that this is just a follow-up error?

In one of the mails from yesterday I showed you my patch to disable 1000
MB/s ... and still I had the link-always-down.

Similarly when I used a 10/100 MB/s switch only.

Both scenarios disabled 1000 MB/s, one more strictly than the other :-)

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi,

> Thanks. I'm suspecting we may need to instrument igb_rd32 at this
> point. In order to trigger what you are seeing I am assuming the
> device has been detached due to a read failure of some sort.

Okay, I added a printk to igb_rd32. And because no one calls this
function directly (all access goes via the rd32/rd32_array macro) I also
added the output of the calling function. This should help greatly in
identifying the read from the hardware to the consumer.

Finally, I noticed that igb_update_stats() produced a lot of churn that
most likely are unrelated. So I helper variable to make output from this
function go away.

I installed this modified driver, rebooted, and removed / inserted the
LAN cable until the error was present.

As before, "ethtool" and "mii-tool" now said that the device is not
there, while "ip link" showed the device as present.


The full output of "journalctl -fk | grep igb" is 600 kB. So put the
whole file at Google Drive:

https://drive.google.com/open?id=1p9cCT2d_EHnSHh29oS3AepUgFTKGFSeA



I looked at the output to see patterns, e.g with

grep -n igb_get_cfg_done_i210 igb.error.txt
grep -n __igb_shutdown igb.error.txt
...

(and almost all other function names). I hoped to see patterns. But for
my untrained eye, things looked not out of the order.





(For reference, here is the debug patch)

Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_main.c   2018-04-01 
23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c2018-04-26 
10:36:09.625135952 +0200
@@ -759,7 +759,8 @@
}
 }
 
-u32 igb_rd32(struct e1000_hw *hw, u32 reg)
+int igb_rd32_silent = 0;
+u32 igb_rd32(const char *func, struct e1000_hw *hw, u32 reg)
 {
struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
@@ -769,6 +770,8 @@
return ~value;
 
value = readl(_addr[reg]);
+   if (!igb_rd32_silent)
+   printk("rd32 %s %08x %08x\n", func, reg, value);
 
/* reads should not return all F's */
if (!(~value) && (!reg || !(~readl(hw_addr {
@@ -5935,6 +5938,7 @@
if (pci_channel_offline(pdev))
return;
 
+   igb_rd32_silent = 1;
bytes = 0;
packets = 0;
 
@@ -6100,6 +6104,7 @@
adapter->stats.b2ospc += rd32(E1000_B2OSPC);
adapter->stats.b2ogprc += rd32(E1000_B2OGPRC);
}
+   igb_rd32_silent = 0;
 }
 
 static void igb_tsync_interrupt(struct igb_adapter *adapter)
Index: linux-4.16/drivers/net/ethernet/intel/igb/e1000_regs.h
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/e1000_regs.h 2018-04-01 
23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/e1000_regs.h  2018-04-26 
10:34:24.332157000 +0200
@@ -370,7 +370,8 @@
 
 struct e1000_hw;
 
-u32 igb_rd32(struct e1000_hw *hw, u32 reg);
+extern int igb_rd32_silent;
+u32 igb_rd32(const char *fname, struct e1000_hw *hw, u32 reg);
 
 /* write operations, indexed using DWORDS */
 #define wr32(reg, val) \
@@ -380,14 +381,14 @@
writel((val), _addr[(reg)]); \
 } while (0)
 
-#define rd32(reg) (igb_rd32(hw, reg))
+#define rd32(reg) (igb_rd32(__func__, hw, reg))
 
 #define wrfl() ((void)rd32(E1000_STATUS))
 
 #define array_wr32(reg, offset, value) \
wr32((reg) + ((offset) << 2), (value))
 
-#define array_rd32(reg, offset) (igb_rd32(hw, reg + ((offset) << 2)))
+#define array_rd32(reg, offset) (igb_rd32(__func__, hw, reg + ((offset) << 2)))
 
 /* DMA Coalescing registers */
 #define E1000_PCIEMISC 0x05BB8 /* PCIE misc config register */

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi,

> Thanks. I'm suspecting we may need to instrument igb_rd32 at this
> point. In order to trigger what you are seeing I am assuming the
> device has been detached due to a read failure of some sort.

Okay, I added a printk to igb_rd32. And because no one calls this
function directly (all access goes via the rd32/rd32_array macro) I also
added the output of the calling function. This should help greatly in
identifying the read from the hardware to the consumer.

Finally, I noticed that igb_update_stats() produced a lot of churn that
most likely are unrelated. So I helper variable to make output from this
function go away.

I installed this modified driver, rebooted, and removed / inserted the
LAN cable until the error was present.

As before, "ethtool" and "mii-tool" now said that the device is not
there, while "ip link" showed the device as present.


The full output of "journalctl -fk | grep igb" is 600 kB. So put the
whole file at Google Drive:

https://drive.google.com/open?id=1p9cCT2d_EHnSHh29oS3AepUgFTKGFSeA



I looked at the output to see patterns, e.g with

grep -n igb_get_cfg_done_i210 igb.error.txt
grep -n __igb_shutdown igb.error.txt
...

(and almost all other function names). I hoped to see patterns. But for
my untrained eye, things looked not out of the order.





(For reference, here is the debug patch)

Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_main.c   2018-04-01 
23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c2018-04-26 
10:36:09.625135952 +0200
@@ -759,7 +759,8 @@
}
 }
 
-u32 igb_rd32(struct e1000_hw *hw, u32 reg)
+int igb_rd32_silent = 0;
+u32 igb_rd32(const char *func, struct e1000_hw *hw, u32 reg)
 {
struct igb_adapter *igb = container_of(hw, struct igb_adapter, hw);
u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
@@ -769,6 +770,8 @@
return ~value;
 
value = readl(_addr[reg]);
+   if (!igb_rd32_silent)
+   printk("rd32 %s %08x %08x\n", func, reg, value);
 
/* reads should not return all F's */
if (!(~value) && (!reg || !(~readl(hw_addr {
@@ -5935,6 +5938,7 @@
if (pci_channel_offline(pdev))
return;
 
+   igb_rd32_silent = 1;
bytes = 0;
packets = 0;
 
@@ -6100,6 +6104,7 @@
adapter->stats.b2ospc += rd32(E1000_B2OSPC);
adapter->stats.b2ogprc += rd32(E1000_B2OGPRC);
}
+   igb_rd32_silent = 0;
 }
 
 static void igb_tsync_interrupt(struct igb_adapter *adapter)
Index: linux-4.16/drivers/net/ethernet/intel/igb/e1000_regs.h
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/e1000_regs.h 2018-04-01 
23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/e1000_regs.h  2018-04-26 
10:34:24.332157000 +0200
@@ -370,7 +370,8 @@
 
 struct e1000_hw;
 
-u32 igb_rd32(struct e1000_hw *hw, u32 reg);
+extern int igb_rd32_silent;
+u32 igb_rd32(const char *fname, struct e1000_hw *hw, u32 reg);
 
 /* write operations, indexed using DWORDS */
 #define wr32(reg, val) \
@@ -380,14 +381,14 @@
writel((val), _addr[(reg)]); \
 } while (0)
 
-#define rd32(reg) (igb_rd32(hw, reg))
+#define rd32(reg) (igb_rd32(__func__, hw, reg))
 
 #define wrfl() ((void)rd32(E1000_STATUS))
 
 #define array_wr32(reg, offset, value) \
wr32((reg) + ((offset) << 2), (value))
 
-#define array_rd32(reg, offset) (igb_rd32(hw, reg + ((offset) << 2)))
+#define array_rd32(reg, offset) (igb_rd32(__func__, hw, reg + ((offset) << 2)))
 
 /* DMA Coalescing registers */
 #define E1000_PCIEMISC 0x05BB8 /* PCIE misc config register */

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

> Was the orange LED on the igb NIC or on the TL SG-108? Based on the
> comment below I am assuming it is the switch.

The LEDs were on the switch.

When everything works, the switch says green == 1000 MB/s.

When cable is disconnected, switch doesn't light any LED.

When cable is inserted and things fail, the switch says orange LED == 100 MB/s.
Sometimes the insertion process works, then the switch will go, of
course, to the green LED == 1000 MB/s.

I must admit that I didn't look at the LEDs of the device.


Now I looked there, and the device the left+green LED is on. In the
failed case (so, in the dmesg output the last thing I see is "Link is
Down", but the device still has left+green LED on.

The right+orange LED on the device seems to indicate traffic, and it is
constantly off in the failed case.



> I assume you mean "ethtool -r" since that is what is supposed to be
> restarting negotiation. The "ethtool -i" is what you provided above.

Maybe I've edited my text too much and moved output along. Anyway, in
the failed case neither "ethtool- r eth0" nor "ethtool -i eth0" nor
"mii-tool eth0" work at all, they all emit error warning.

> Thanks. I'm suspecting we may need to instrument igb_rd32 at this
> point. In order to trigger what you are seeing I am assuming the
> device has been detached due to a read failure of some sort.

I'll do that and reply later. I first need to understand this source
part :-)


> Another thing you could look at doing is narrowing down the possible
> factors involved. You could go through and limit phy settings and look
> at possibly dropping features such as EEE if it is enabled on the
> device.

I actually tried a driver patch to remove 1000 GB/s from the driver, in
the assumption that maybe this specific hardware has a bad layout and
thus trouble (I don't really think that, because I never observed any
data transfer problem).

So, is the following patch (that didn't help) what in the line of what
you suggested?


Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_main.c   2018-04-01 
23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c2018-04-24 
11:35:17.420760650 +0200
@@ -2080,7 +2080,7 @@
 
if ((adapter->flags & IGB_FLAG_EEE) &&
(!hw->dev_spec._82575.eee_disable))
-   adapter->eee_advert = MDIO_EEE_100TX | MDIO_EEE_1000T;
+   adapter->eee_advert = MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
 
return 0;
 }
@@ -2908,7 +2908,7 @@
/* Initialize link properties that are user-changeable */
adapter->fc_autoneg = true;
hw->mac.autoneg = true;
-   hw->phy.autoneg_advertised = 0x2f;
+   hw->phy.autoneg_advertised = 0x0f;
 
hw->fc.requested_mode = e1000_fc_default;
hw->fc.current_mode = e1000_fc_default;
@@ -3099,7 +3099,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
-   MDIO_EEE_100TX | MDIO_EEE_1000T;
+   MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
adapter->flags |= IGB_FLAG_EEE;
}
break;
@@ -3110,7 +3110,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
-  MDIO_EEE_100TX | MDIO_EEE_1000T;
+  MDIO_EEE_100TX /* | MDIO_EEE_1000T 
*/;
adapter->flags |= IGB_FLAG_EEE;
}
}
Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_ethtool.c
2018-04-01 23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c 2018-04-24 
11:42:36.737959749 +0200
@@ -170,7 +170,7 @@
 SUPPORTED_10baseT_Full |
 SUPPORTED_100baseT_Half |
 SUPPORTED_100baseT_Full |
-SUPPORTED_1000baseT_Full|
+/* SUPPORTED_1000baseT_Full| */ 
 SUPPORTED_Autoneg |
 SUPPORTED_TP |
 SUPPORTED_Pause);
@@ -3003,7 +3003,7 @@
(hw->phy.media_type != e1000_media_type_copper))
return -EOPNOTSUPP;
 
-   edata->supported = (SUPPORTED_1000baseT_Full |
+   edata->supported = (/* SUPPORTED_1000baseT_Full | */
SUPPORTED_100baseT_Full);
if 

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

> Was the orange LED on the igb NIC or on the TL SG-108? Based on the
> comment below I am assuming it is the switch.

The LEDs were on the switch.

When everything works, the switch says green == 1000 MB/s.

When cable is disconnected, switch doesn't light any LED.

When cable is inserted and things fail, the switch says orange LED == 100 MB/s.
Sometimes the insertion process works, then the switch will go, of
course, to the green LED == 1000 MB/s.

I must admit that I didn't look at the LEDs of the device.


Now I looked there, and the device the left+green LED is on. In the
failed case (so, in the dmesg output the last thing I see is "Link is
Down", but the device still has left+green LED on.

The right+orange LED on the device seems to indicate traffic, and it is
constantly off in the failed case.



> I assume you mean "ethtool -r" since that is what is supposed to be
> restarting negotiation. The "ethtool -i" is what you provided above.

Maybe I've edited my text too much and moved output along. Anyway, in
the failed case neither "ethtool- r eth0" nor "ethtool -i eth0" nor
"mii-tool eth0" work at all, they all emit error warning.

> Thanks. I'm suspecting we may need to instrument igb_rd32 at this
> point. In order to trigger what you are seeing I am assuming the
> device has been detached due to a read failure of some sort.

I'll do that and reply later. I first need to understand this source
part :-)


> Another thing you could look at doing is narrowing down the possible
> factors involved. You could go through and limit phy settings and look
> at possibly dropping features such as EEE if it is enabled on the
> device.

I actually tried a driver patch to remove 1000 GB/s from the driver, in
the assumption that maybe this specific hardware has a bad layout and
thus trouble (I don't really think that, because I never observed any
data transfer problem).

So, is the following patch (that didn't help) what in the line of what
you suggested?


Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_main.c   2018-04-01 
23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c2018-04-24 
11:35:17.420760650 +0200
@@ -2080,7 +2080,7 @@
 
if ((adapter->flags & IGB_FLAG_EEE) &&
(!hw->dev_spec._82575.eee_disable))
-   adapter->eee_advert = MDIO_EEE_100TX | MDIO_EEE_1000T;
+   adapter->eee_advert = MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
 
return 0;
 }
@@ -2908,7 +2908,7 @@
/* Initialize link properties that are user-changeable */
adapter->fc_autoneg = true;
hw->mac.autoneg = true;
-   hw->phy.autoneg_advertised = 0x2f;
+   hw->phy.autoneg_advertised = 0x0f;
 
hw->fc.requested_mode = e1000_fc_default;
hw->fc.current_mode = e1000_fc_default;
@@ -3099,7 +3099,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
-   MDIO_EEE_100TX | MDIO_EEE_1000T;
+   MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
adapter->flags |= IGB_FLAG_EEE;
}
break;
@@ -3110,7 +3110,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
-  MDIO_EEE_100TX | MDIO_EEE_1000T;
+  MDIO_EEE_100TX /* | MDIO_EEE_1000T 
*/;
adapter->flags |= IGB_FLAG_EEE;
}
}
Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c
===
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_ethtool.c
2018-04-01 23:20:27.0 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c 2018-04-24 
11:42:36.737959749 +0200
@@ -170,7 +170,7 @@
 SUPPORTED_10baseT_Full |
 SUPPORTED_100baseT_Half |
 SUPPORTED_100baseT_Full |
-SUPPORTED_1000baseT_Full|
+/* SUPPORTED_1000baseT_Full| */ 
 SUPPORTED_Autoneg |
 SUPPORTED_TP |
 SUPPORTED_Pause);
@@ -3003,7 +3003,7 @@
(hw->phy.media_type != e1000_media_type_copper))
return -EOPNOTSUPP;
 
-   edata->supported = (SUPPORTED_1000baseT_Full |
+   edata->supported = (/* SUPPORTED_1000baseT_Full | */
SUPPORTED_100baseT_Full);
if 

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi Alex,

(Sent a 2nd time, this time with "Reply to all" and without HTML, so
that it hits the kernel archives as well. Sorry for the noise.




> Sounds like the link is failing to re-establish. You might double
> check a few things. One is to verify if the link partner is
> recognizing the link as coming up or not.

It turns on differently. Before I remove the cable, the LED on the TP
LINK "TL SG-108" was green. After removing the cable, the LED went off.
After reinserting the cable, it became orange after some while.

Green LED means 1000 MB/s, orange LED means 10/100 MB/s.


I have a different, even older switch: "Allnet ALL8039". Here the same:
the switch detects a link, but igb not.



> If you could also provide an "lspci -vvv"

02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR-  and "ethtool -i" for the

driver: igb
version: 5.4.0-k
firmware-version: 3.20, 0x8553
expansion-rom-version:
bus-info: :02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes



One thing that is interesting is how igb reacts to ethtool inquiries
once it goes into the failed state. You inquired for "ethtool -i eth0",
but in the failed state I only get this:

Cannot restart autonegotiation: No such device

But eth0 is of course still there, "ip -d link show eth0" shows:


2: eth0:  mtu 1500 qdisc mq state DOWN
mode DEFAULT group default qlen 1000
link/ether 00:13:95:1a:54:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535





Other ethtool commands also don't report any information once the link
went bogus. Here one output from "ethtool eth0":

Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes

... and here another:

Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
Settings for eth0:
No data available



I'm willing to pepper the source with printk, if this helps :-)


Greetings,
Holger

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi Alex,

(Sent a 2nd time, this time with "Reply to all" and without HTML, so
that it hits the kernel archives as well. Sorry for the noise.




> Sounds like the link is failing to re-establish. You might double
> check a few things. One is to verify if the link partner is
> recognizing the link as coming up or not.

It turns on differently. Before I remove the cable, the LED on the TP
LINK "TL SG-108" was green. After removing the cable, the LED went off.
After reinserting the cable, it became orange after some while.

Green LED means 1000 MB/s, orange LED means 10/100 MB/s.


I have a different, even older switch: "Allnet ALL8039". Here the same:
the switch detects a link, but igb not.



> If you could also provide an "lspci -vvv"

02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR-  and "ethtool -i" for the

driver: igb
version: 5.4.0-k
firmware-version: 3.20, 0x8553
expansion-rom-version:
bus-info: :02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes



One thing that is interesting is how igb reacts to ethtool inquiries
once it goes into the failed state. You inquired for "ethtool -i eth0",
but in the failed state I only get this:

Cannot restart autonegotiation: No such device

But eth0 is of course still there, "ip -d link show eth0" shows:


2: eth0:  mtu 1500 qdisc mq state DOWN
mode DEFAULT group default qlen 1000
link/ether 00:13:95:1a:54:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535





Other ethtool commands also don't report any information once the link
went bogus. Here one output from "ethtool eth0":

Settings for eth0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x0007 (7)
   drv probe link
Link detected: yes

... and here another:

Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
Settings for eth0:
No data available



I'm willing to pepper the source with printk, if this helps :-)


Greetings,
Holger

[BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi all,

I'm on kernel 4.16.4 and have an issue with eth0, driver is igb. When I
remove the ethernet cable, this is always detected:

[2.772360] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[2.772363] igb: Copyright (c) 2007-2014 Intel Corporation.
[3.023707] igb :02:00.0: added PHC on eth0
[3.023710] igb :02:00.0: Intel(R) Gigabit Ethernet Network Connection
[3.023713] igb :02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:13:95:1a:54:33
[3.023758] igb :02:00.0: eth0: PBA No: 000300-000
[3.023762] igb :02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx 
queue(s)
[7.984921] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX
[   11.184593] igb :02:00.0 eth0: igb: eth0 NIC Link is Down

Sometimes, plugging the cable back in is detected ...

[   43.736922] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX

... but sometimes this is *NOT* detected. I can put the cable in and
even after two minutes nothing has been detected.

But when I run "rmmod igb" followed by "modpobe igb", the link is
detected again:

[  100.528609] igb :02:00.0 eth0: igb: eth0 NIC Link is Down
[ 2336.583244] igb :02:00.0: removed PHC on eth0
[ 2339.693521] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[ 2339.693524] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 2339.990553] pps pps0: new PPS source ptp0
[ 2339.990561] igb :02:00.0: added PHC on eth0
[ 2339.990565] igb :02:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 2339.990569] igb :02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:13:95:1a:54:33
[ 2339.990611] igb :02:00.0: eth0: PBA No: 000300-000
[ 2339.990615] igb :02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx 
queue(s)
[ 2343.001114] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX

(In above dmesg snippet the ethernet cable was the whole time inserted).


Any tips on how I can debug this further?

PS: I already tried a different switch and also a direct connection from
device-to-device, without a switch.

[BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi all,

I'm on kernel 4.16.4 and have an issue with eth0, driver is igb. When I
remove the ethernet cable, this is always detected:

[2.772360] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[2.772363] igb: Copyright (c) 2007-2014 Intel Corporation.
[3.023707] igb :02:00.0: added PHC on eth0
[3.023710] igb :02:00.0: Intel(R) Gigabit Ethernet Network Connection
[3.023713] igb :02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:13:95:1a:54:33
[3.023758] igb :02:00.0: eth0: PBA No: 000300-000
[3.023762] igb :02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx 
queue(s)
[7.984921] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX
[   11.184593] igb :02:00.0 eth0: igb: eth0 NIC Link is Down

Sometimes, plugging the cable back in is detected ...

[   43.736922] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX

... but sometimes this is *NOT* detected. I can put the cable in and
even after two minutes nothing has been detected.

But when I run "rmmod igb" followed by "modpobe igb", the link is
detected again:

[  100.528609] igb :02:00.0 eth0: igb: eth0 NIC Link is Down
[ 2336.583244] igb :02:00.0: removed PHC on eth0
[ 2339.693521] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[ 2339.693524] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 2339.990553] pps pps0: new PPS source ptp0
[ 2339.990561] igb :02:00.0: added PHC on eth0
[ 2339.990565] igb :02:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 2339.990569] igb :02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) 00:13:95:1a:54:33
[ 2339.990611] igb :02:00.0: eth0: PBA No: 000300-000
[ 2339.990615] igb :02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx 
queue(s)
[ 2343.001114] igb :02:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: RX/TX

(In above dmesg snippet the ethernet cable was the whole time inserted).


Any tips on how I can debug this further?

PS: I already tried a different switch and also a direct connection from
device-to-device, without a switch.

BUG: serial: imx: imprecise data abort

[Holger Schurig]

Hi all,

on an i.MX6Q we had a situation where we got "Imprecise Data Aborts".
The backtraces of those aborts were useless, all over the place.

But we found out that we can trigger this bug with this procedure:

- make some external PC send constantly through the serial port
  to the i.MX6Q.
- run a serial program on the i.MX6Q that receives the data and
  echos it back
- let this program terminate and restart every over second (we
  used a 4 second interval)

Chances were good that we reproduced the issue with various kernels
(up to 4.7.2).


In the drivers/tty/serial/tty/imx.c I disabled all DMA, because this was
my first suspicion. But to no avail. Eventually we asked some company
to help us. They produced the following patch. With this patch, we can
now run for a long time without any imprecise data abort (actually we
run into another issue, but according to
https://lkml.org/lkml/2016/5/16/452 "tty crash in Linux 4.6" this is
already in the working).

It's entirely clear to me that below WIP-patch has ZERO chance of being
added. It's not just checkpatch that will barf over it. :-)

My goal is to make the more knowledgeable people aware of the issue and
to give them a pointer, so that they can tell me how to fix the issue
in a correct way.


Holger




--- linux-4.6.orig/drivers/tty/serial/imx.c
+++ linux-4.6/drivers/tty/serial/imx.c
@@ -234,6 +234,9 @@
unsigned intucr3;
 };
 
+static unsigned int DBG_Starttx = 0;
+atomic_t imx_uart_is_in_irq = ATOMIC_INIT(0);
+
 static struct imx_uart_data imx_uart_devdata[] = {
[IMX1_UART] = {
.uts_reg = IMX1_UTS,
@@ -386,8 +389,8 @@
}
}
 
-   temp = readl(sport->port.membase + UCR2);
-   writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
+   //temp = readl(sport->port.membase + UCR2);
+   //writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 
/* disable the `Receiver Ready Interrrupt` */
temp = readl(sport->port.membase + UCR1);
@@ -577,6 +580,7 @@
}
 
if (!sport->dma_is_enabled) {
+   //DBG_Starttx++;
temp = readl(sport->port.membase + UCR1);
writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
}
spin_lock_irqsave(>port.lock, flags);
 
while (readl(sport->port.membase + USR2) & USR2_RDR) {
+   //skip if not enabled 
+   if(((readl(sport->port.membase + UCR2) & UCR2_RXEN) ==0 )
+  || ((readl(sport->port.membase + UCR1) & UCR1_UARTEN) ==0 ))
+   goto out;
+   
flg = TTY_NORMAL;
sport->port.icount.rx++;
+
+   
 
rx = readl(sport->port.membase + URXD0);
 
@@ -735,6 +746,7 @@
unsigned int sts;
unsigned int sts2;
 
+   atomic_add(1,_uart_is_in_irq);
sts = readl(sport->port.membase + USR1);
sts2 = readl(sport->port.membase + USR2);
 
@@ -761,7 +773,7 @@
sport->port.icount.overrun++;
writel(USR2_ORE, sport->port.membase + USR2);
}
-
+   atomic_sub(1,_uart_is_in_irq);
return IRQ_HANDLED;
 }
 
@@ -896,6 +908,7 @@
struct imx_port *sport = (struct imx_port *)data;
unsigned long flags;
 
+   atomic_add(1,_uart_is_in_irq);
if (sport->port.state) {
spin_lock_irqsave(>port.lock, flags);
imx_mctrl_check(sport);
@@ -903,6 +916,7 @@
 
mod_timer(>timer, jiffies + MCTRL_TIMEOUT);
}
+   atomic_sub(1,_uart_is_in_irq);
 }
 
 #define RX_BUF_SIZE(PAGE_SIZE)
@@ -1251,7 +1267,7 @@
}
spin_lock_irqsave(>port.lock, flags);
imx_stop_tx(port);
-   imx_stop_rx(port);
+// imx_stop_rx(port);
imx_disable_dma(sport);
spin_unlock_irqrestore(>port.lock, flags);
imx_uart_dma_exit(sport);
@@ -1261,7 +1277,7 @@
 
spin_lock_irqsave(>port.lock, flags);
temp = readl(sport->port.membase + UCR2);
-   temp &= ~(UCR2_TXEN);
+   //temp &= ~(UCR2_TXEN);
writel(temp, sport->port.membase + UCR2);
spin_unlock_irqrestore(>port.lock, flags);
 
@@ -1276,13 +1292,16 @@
 
spin_lock_irqsave(>port.lock, flags);
temp = readl(sport->port.membase + UCR1);
-   temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
+   //temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
+   temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN);
 
writel(temp, sport->port.membase + UCR1);
spin_unlock_irqrestore(>port.lock, flags);
 
-   clk_disable_unprepare(sport->clk_per);
-   clk_disable_unprepare(sport->clk_ipg);
+   while(atomic_read(_uart_is_in_irq) == 1);
+
+   //clk_disable_unprepare(sport->clk_per);
+   //clk_disable_unprepare(sport->clk_ipg);
 }
 
 static void imx_flush_buffer(struct uart_port 

BUG: serial: imx: imprecise data abort

[Holger Schurig]

Hi all,

on an i.MX6Q we had a situation where we got "Imprecise Data Aborts".
The backtraces of those aborts were useless, all over the place.

But we found out that we can trigger this bug with this procedure:

- make some external PC send constantly through the serial port
  to the i.MX6Q.
- run a serial program on the i.MX6Q that receives the data and
  echos it back
- let this program terminate and restart every over second (we
  used a 4 second interval)

Chances were good that we reproduced the issue with various kernels
(up to 4.7.2).


In the drivers/tty/serial/tty/imx.c I disabled all DMA, because this was
my first suspicion. But to no avail. Eventually we asked some company
to help us. They produced the following patch. With this patch, we can
now run for a long time without any imprecise data abort (actually we
run into another issue, but according to
https://lkml.org/lkml/2016/5/16/452 "tty crash in Linux 4.6" this is
already in the working).

It's entirely clear to me that below WIP-patch has ZERO chance of being
added. It's not just checkpatch that will barf over it. :-)

My goal is to make the more knowledgeable people aware of the issue and
to give them a pointer, so that they can tell me how to fix the issue
in a correct way.


Holger




--- linux-4.6.orig/drivers/tty/serial/imx.c
+++ linux-4.6/drivers/tty/serial/imx.c
@@ -234,6 +234,9 @@
unsigned intucr3;
 };
 
+static unsigned int DBG_Starttx = 0;
+atomic_t imx_uart_is_in_irq = ATOMIC_INIT(0);
+
 static struct imx_uart_data imx_uart_devdata[] = {
[IMX1_UART] = {
.uts_reg = IMX1_UTS,
@@ -386,8 +389,8 @@
}
}
 
-   temp = readl(sport->port.membase + UCR2);
-   writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
+   //temp = readl(sport->port.membase + UCR2);
+   //writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 
/* disable the `Receiver Ready Interrrupt` */
temp = readl(sport->port.membase + UCR1);
@@ -577,6 +580,7 @@
}
 
if (!sport->dma_is_enabled) {
+   //DBG_Starttx++;
temp = readl(sport->port.membase + UCR1);
writel(temp | UCR1_TXMPTYEN, sport->port.membase + UCR1);
}
spin_lock_irqsave(>port.lock, flags);
 
while (readl(sport->port.membase + USR2) & USR2_RDR) {
+   //skip if not enabled 
+   if(((readl(sport->port.membase + UCR2) & UCR2_RXEN) ==0 )
+  || ((readl(sport->port.membase + UCR1) & UCR1_UARTEN) ==0 ))
+   goto out;
+   
flg = TTY_NORMAL;
sport->port.icount.rx++;
+
+   
 
rx = readl(sport->port.membase + URXD0);
 
@@ -735,6 +746,7 @@
unsigned int sts;
unsigned int sts2;
 
+   atomic_add(1,_uart_is_in_irq);
sts = readl(sport->port.membase + USR1);
sts2 = readl(sport->port.membase + USR2);
 
@@ -761,7 +773,7 @@
sport->port.icount.overrun++;
writel(USR2_ORE, sport->port.membase + USR2);
}
-
+   atomic_sub(1,_uart_is_in_irq);
return IRQ_HANDLED;
 }
 
@@ -896,6 +908,7 @@
struct imx_port *sport = (struct imx_port *)data;
unsigned long flags;
 
+   atomic_add(1,_uart_is_in_irq);
if (sport->port.state) {
spin_lock_irqsave(>port.lock, flags);
imx_mctrl_check(sport);
@@ -903,6 +916,7 @@
 
mod_timer(>timer, jiffies + MCTRL_TIMEOUT);
}
+   atomic_sub(1,_uart_is_in_irq);
 }
 
 #define RX_BUF_SIZE(PAGE_SIZE)
@@ -1251,7 +1267,7 @@
}
spin_lock_irqsave(>port.lock, flags);
imx_stop_tx(port);
-   imx_stop_rx(port);
+// imx_stop_rx(port);
imx_disable_dma(sport);
spin_unlock_irqrestore(>port.lock, flags);
imx_uart_dma_exit(sport);
@@ -1261,7 +1277,7 @@
 
spin_lock_irqsave(>port.lock, flags);
temp = readl(sport->port.membase + UCR2);
-   temp &= ~(UCR2_TXEN);
+   //temp &= ~(UCR2_TXEN);
writel(temp, sport->port.membase + UCR2);
spin_unlock_irqrestore(>port.lock, flags);
 
@@ -1276,13 +1292,16 @@
 
spin_lock_irqsave(>port.lock, flags);
temp = readl(sport->port.membase + UCR1);
-   temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
+   //temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
+   temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN);
 
writel(temp, sport->port.membase + UCR1);
spin_unlock_irqrestore(>port.lock, flags);
 
-   clk_disable_unprepare(sport->clk_per);
-   clk_disable_unprepare(sport->clk_ipg);
+   while(atomic_read(_uart_is_in_irq) == 1);
+
+   //clk_disable_unprepare(sport->clk_per);
+   //clk_disable_unprepare(sport->clk_ipg);
 }
 
 static void imx_flush_buffer(struct uart_port 

Re: Sharing code between Linux and bootloader (U-boot) ?

[Holger Schurig]

Sebastian Frias  writes:

Barebox shares a good amount of code. For example, when you look at SPI
at AT24/AT25 you'll see that many things are almost identical.

Re: Sharing code between Linux and bootloader (U-boot) ?

[Holger Schurig]

Sebastian Frias  writes:

Barebox shares a good amount of code. For example, when you look at SPI
at AT24/AT25 you'll see that many things are almost identical.

Re: [PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92

[Holger Schurig]

Thierry Reding  writes:
> Applied, thanks.

I once read that this is the recommended way to go, instead of
specifying the timings in the device tree. Why is this so?  Any new
display just increases the .text size of the kernel unnessary.

Did this idea stem from the era where bootloaders like Barebox couldn't
modify the DT ad-hoc before handing it over to the kernel?

Re: [PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92

[Holger Schurig]

Thierry Reding  writes:
> Applied, thanks.

I once read that this is the recommended way to go, instead of
specifying the timings in the device tree. Why is this so?  Any new
display just increases the .text size of the kernel unnessary.

Did this idea stem from the era where bootloaders like Barebox couldn't
modify the DT ad-hoc before handing it over to the kernel?

Re: [PATCH 1/3] leds: trigger: Introduce a kernel panic LED trigger

[Holger Schurig]

> (Interestingly, it also blinks the LEDs on a USB keyboard!)

Assuming USB is still working after a kernel panic ...

Re: [PATCH 1/3] leds: trigger: Introduce a kernel panic LED trigger

[Holger Schurig]

> (Interestingly, it also blinks the LEDs on a USB keyboard!)

Assuming USB is still working after a kernel panic ...

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

I have rejoiced prematurely, it just now took way longer I hit the
segfault. Previously 1m or at max 2m was enough.

root@ptxc:~# stress-ng --sock 20
stress-ng: info: [359] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 20 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
[   42.253392] random: nonblocking pool is initialized
[  567.649965] Unable to handle kernel NULL pointer dereference at virtual 
address 0104
[  567.658087] pgd = ee11c000
[  567.660797] [0104] *pgd=3eaf4831, *pte=, *ppte=
[  567.667112] Internal error: Oops: 817 [#1] SMP ARM
[  567.671904] Modules linked in: bnep btusb btrtl btbcm btintel bluetooth 
smsc95xx usbnet usbhid mii imx_sdma flexcan
[  567.682514] CPU: 1 PID: 383 Comm: stress-ng-socke Not tainted 4.4.4PTXC #3
[  567.689390] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  567.695920] task: ed9f9e00 ti: eeaf task.ti: eeaf
[  567.701333] PC is at __rmqueue+0x74/0x308
[  567.705346] LR is at 0x3
[  567.707882] pc : []lr : [<0003>]psr: 60030093
[  567.707882] sp : eeaf1c00  ip : 0200  fp : eeaf1c4c
[  567.719359] r10: efd5f514  r9 : 0008  r8 : 
[  567.724585] r7 : 0003  r6 :   r5 : c051343c  r4 : 0100
[  567.731113] r3 : c05d6e2c  r2 : 006c  r1 : 0200  r0 : 0100
[  567.737643] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[  567.744866] Control: 10c5387d  Table: 3e11c04a  DAC: 0051
[  567.750612] Process stress-ng-socke (pid: 383, stack limit = 0xeeaf0210)
[  567.757314] Stack: (0xeeaf1c00 to 0xeeaf2000)
[  567.761677] 1c00:  c05d3200 ed976880 ed976880 eeaf1c54 c05d6d40 
c03dc720 c03da9e8
[  567.769859] 1c20: 20030013 eeaf1d54 c051343c c0513428 c0513428 6104de4b 
0008 c05d6d40
[  567.778040] 1c40: eeaf1ce4 eeaf1c50 c0097d84 c0097364 0141 0002a602 
ef7bc2c0 0018
[  567.786220] 1c60: c05d77c0 c05d77c0  c05d6d40   
 
[  567.794401] 1c80: 0100 c05d6f50 c05d77c8 c05d6e68 c05d78d5 0128 
0141 020252c0
[  567.802582] 1ca0:  fff8  eeaf1d54 60030013 0003 
 020052c0
[  567.810762] 1cc0: 0003 c05d77c0 ffcb 6104de4b eeaf1e84  
eeaf1d9c eeaf1ce8
[  567.818942] 1ce0: c0098154 c009766c c006cb38 00100010 60ecb9db 40030013 
eeaf1d1c ed976880
[  567.827123] 1d00: ed976880 0004 eacecc00 ed976880 eeaf1d84 eeaf1d20 
c03f4d44 c03f2c30
[  567.835304] 1d20: 0002 ef001c00  024102c0  000346db 
c05b8100 
[  567.843484] 1d40: 0002 ed976c14 0002   c05d77c0 
 c05d6d40
[  567.851664] 1d60:     eeaf1e84 ed9fa2b4 
024000c0 0fb0
[  567.859845] 1d80: ffcb 6104de4b eeaf1e84  eeaf1db4 eeaf1da0 
c03901d4 c0098088
[  567.868025] 1da0: ed976880 ed976880 eeaf1dcc eeaf1db8 c039024c c0390170 
eaf60600 ed976880
[  567.876206] 1dc0: eeaf1e4c eeaf1dd0 c03e83fc c039023c ffcb 0001 
23c09b2d 17c8
[  567.884386] 1de0: 0001 eeaf1e8c c05b8bb4 eeaf 0001  
ed9fa2b4 
[  567.892566] 1e00: 0001 ed976938 ffcb 0c90 c004c6d8 ffcb 
7fff c00473e8
[  567.900747] 1e20: ed983c80 ed976880    eea03780 
eeaf 
[  567.908927] 1e40: eeaf1e6c eeaf1e50 c040ec5c c03e8228   
eeaf1eec 
[  567.917107] 1e60: eeaf1e7c eeaf1e70 c038c308 c040ebd4 eeaf1ed4 eeaf1e80 
c038c3a4 c038c2f8
[  567.925287] 1e80: c0050004   0001 0c90 0fb0 
eeaf1ee4 0001
[  567.933467] 1ea0:    eeaf1f00 afb50401 eea03780 
eeaf1f80 
[  567.941647] 1ec0:  c000fae4 eeaf1f3c eeaf1ed8 c00cfe84 c038c324 
1c40 ef0a4000
[  567.949828] 1ee0: eeaf1f14 bef469bc 1c40 0001  1c40 
eeaf1ee4 0001
[  567.958008] 1f00: eea03780      
 
[  567.966189] 1f20: eea03780 1c40 bef469bc eeaf1f80 eeaf1f4c eeaf1f40 
c00cfedc c00cfe08
[  567.974369] 1f40: eeaf1f7c eeaf1f50 c00d0688 c00cfeb4   
eeaf1f7c eea03780
[  567.982550] 1f60: eea03780 1c40 bef469bc c000fae4 eeaf1fa4 eeaf1f80 
c00d0f64 c00d05fc
[  567.990730] 1f80:   0004 0002a1e8 b6f94598 0004 
 eeaf1fa8
[  567.998910] 1fa0: c000f920 c00d0f24 0004 0002a1e8 0004 bef469bc 
1c40 bef489bc
[  568.007091] 1fc0: 0004 0002a1e8 b6f94598 0004 1c40 018d 
0002a1f0 0003
[  568.015271] 1fe0:  bef468f4 00014a57 b6ecf4d6 40030030 0004 
 
[  568.023447] Backtrace: 
[  568.025916] [] (__rmqueue) from [] 
(get_page_from_freelist+0x724/0x914)
[  568.034267]  r10:c05d6d40 r9:0008 r8:6104de4b r7:c0513428 r6:c0513428 
r5:c051343c
[  568.042164]  r4:eeaf1d54
[  568.044716] [] 

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

I have rejoiced prematurely, it just now took way longer I hit the
segfault. Previously 1m or at max 2m was enough.

root@ptxc:~# stress-ng --sock 20
stress-ng: info: [359] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 20 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
[   42.253392] random: nonblocking pool is initialized
[  567.649965] Unable to handle kernel NULL pointer dereference at virtual 
address 0104
[  567.658087] pgd = ee11c000
[  567.660797] [0104] *pgd=3eaf4831, *pte=, *ppte=
[  567.667112] Internal error: Oops: 817 [#1] SMP ARM
[  567.671904] Modules linked in: bnep btusb btrtl btbcm btintel bluetooth 
smsc95xx usbnet usbhid mii imx_sdma flexcan
[  567.682514] CPU: 1 PID: 383 Comm: stress-ng-socke Not tainted 4.4.4PTXC #3
[  567.689390] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  567.695920] task: ed9f9e00 ti: eeaf task.ti: eeaf
[  567.701333] PC is at __rmqueue+0x74/0x308
[  567.705346] LR is at 0x3
[  567.707882] pc : []lr : [<0003>]psr: 60030093
[  567.707882] sp : eeaf1c00  ip : 0200  fp : eeaf1c4c
[  567.719359] r10: efd5f514  r9 : 0008  r8 : 
[  567.724585] r7 : 0003  r6 :   r5 : c051343c  r4 : 0100
[  567.731113] r3 : c05d6e2c  r2 : 006c  r1 : 0200  r0 : 0100
[  567.737643] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[  567.744866] Control: 10c5387d  Table: 3e11c04a  DAC: 0051
[  567.750612] Process stress-ng-socke (pid: 383, stack limit = 0xeeaf0210)
[  567.757314] Stack: (0xeeaf1c00 to 0xeeaf2000)
[  567.761677] 1c00:  c05d3200 ed976880 ed976880 eeaf1c54 c05d6d40 
c03dc720 c03da9e8
[  567.769859] 1c20: 20030013 eeaf1d54 c051343c c0513428 c0513428 6104de4b 
0008 c05d6d40
[  567.778040] 1c40: eeaf1ce4 eeaf1c50 c0097d84 c0097364 0141 0002a602 
ef7bc2c0 0018
[  567.786220] 1c60: c05d77c0 c05d77c0  c05d6d40   
 
[  567.794401] 1c80: 0100 c05d6f50 c05d77c8 c05d6e68 c05d78d5 0128 
0141 020252c0
[  567.802582] 1ca0:  fff8  eeaf1d54 60030013 0003 
 020052c0
[  567.810762] 1cc0: 0003 c05d77c0 ffcb 6104de4b eeaf1e84  
eeaf1d9c eeaf1ce8
[  567.818942] 1ce0: c0098154 c009766c c006cb38 00100010 60ecb9db 40030013 
eeaf1d1c ed976880
[  567.827123] 1d00: ed976880 0004 eacecc00 ed976880 eeaf1d84 eeaf1d20 
c03f4d44 c03f2c30
[  567.835304] 1d20: 0002 ef001c00  024102c0  000346db 
c05b8100 
[  567.843484] 1d40: 0002 ed976c14 0002   c05d77c0 
 c05d6d40
[  567.851664] 1d60:     eeaf1e84 ed9fa2b4 
024000c0 0fb0
[  567.859845] 1d80: ffcb 6104de4b eeaf1e84  eeaf1db4 eeaf1da0 
c03901d4 c0098088
[  567.868025] 1da0: ed976880 ed976880 eeaf1dcc eeaf1db8 c039024c c0390170 
eaf60600 ed976880
[  567.876206] 1dc0: eeaf1e4c eeaf1dd0 c03e83fc c039023c ffcb 0001 
23c09b2d 17c8
[  567.884386] 1de0: 0001 eeaf1e8c c05b8bb4 eeaf 0001  
ed9fa2b4 
[  567.892566] 1e00: 0001 ed976938 ffcb 0c90 c004c6d8 ffcb 
7fff c00473e8
[  567.900747] 1e20: ed983c80 ed976880    eea03780 
eeaf 
[  567.908927] 1e40: eeaf1e6c eeaf1e50 c040ec5c c03e8228   
eeaf1eec 
[  567.917107] 1e60: eeaf1e7c eeaf1e70 c038c308 c040ebd4 eeaf1ed4 eeaf1e80 
c038c3a4 c038c2f8
[  567.925287] 1e80: c0050004   0001 0c90 0fb0 
eeaf1ee4 0001
[  567.933467] 1ea0:    eeaf1f00 afb50401 eea03780 
eeaf1f80 
[  567.941647] 1ec0:  c000fae4 eeaf1f3c eeaf1ed8 c00cfe84 c038c324 
1c40 ef0a4000
[  567.949828] 1ee0: eeaf1f14 bef469bc 1c40 0001  1c40 
eeaf1ee4 0001
[  567.958008] 1f00: eea03780      
 
[  567.966189] 1f20: eea03780 1c40 bef469bc eeaf1f80 eeaf1f4c eeaf1f40 
c00cfedc c00cfe08
[  567.974369] 1f40: eeaf1f7c eeaf1f50 c00d0688 c00cfeb4   
eeaf1f7c eea03780
[  567.982550] 1f60: eea03780 1c40 bef469bc c000fae4 eeaf1fa4 eeaf1f80 
c00d0f64 c00d05fc
[  567.990730] 1f80:   0004 0002a1e8 b6f94598 0004 
 eeaf1fa8
[  567.998910] 1fa0: c000f920 c00d0f24 0004 0002a1e8 0004 bef469bc 
1c40 bef489bc
[  568.007091] 1fc0: 0004 0002a1e8 b6f94598 0004 1c40 018d 
0002a1f0 0003
[  568.015271] 1fe0:  bef468f4 00014a57 b6ecf4d6 40030030 0004 
 
[  568.023447] Backtrace: 
[  568.025916] [] (__rmqueue) from [] 
(get_page_from_freelist+0x724/0x914)
[  568.034267]  r10:c05d6d40 r9:0008 r8:6104de4b r7:c0513428 r6:c0513428 
r5:c051343c
[  568.042164]  r4:eeaf1d54
[  568.044716] [] 

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

I compared my config with imx_v6_v7_defconfig which didn't segfault.

After I turned on CONFIG_SWAP, my segfault vanished.

I did turn off CONFIG_SWAP because my device only has SD-Card and eMMC.
So I never intended to create a swap partition. And thought "why compile
it in the kernel when I never use it?".

But it seems the kernel is instable with this setting.

So we have a potential denial-of-service in kernels compiled without
CONFIG_SWAP, don't we? At least when it comes to skb handling.

Other memory tests never showed anything weird, and my system is running
X11 with some Qt applications as well as Java applications since about a
year without trouble. During all this time without CONFIG_SWAP.

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

I compared my config with imx_v6_v7_defconfig which didn't segfault.

After I turned on CONFIG_SWAP, my segfault vanished.

I did turn off CONFIG_SWAP because my device only has SD-Card and eMMC.
So I never intended to create a swap partition. And thought "why compile
it in the kernel when I never use it?".

But it seems the kernel is instable with this setting.

So we have a potential denial-of-service in kernels compiled without
CONFIG_SWAP, don't we? At least when it comes to skb handling.

Other memory tests never showed anything weird, and my system is running
X11 with some Qt applications as well as Java applications since about a
year without trouble. During all this time without CONFIG_SWAP.

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Holger Schurig]

I know that in Germany a good amount of land-line telephone line are
still using ISDN. Some telco company try to move people to IP only, but
this is currently still a process.

Especially company line are using ISDN still, and there are some Linux
programs that act on then, e.g. Asterisk and derived PBX software has
ISDN support which is actively used.

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Holger Schurig]

I know that in Germany a good amount of land-line telephone line are
still using ISDN. Some telco company try to move people to IP only, but
this is currently still a process.

Especially company line are using ISDN still, and there are some Linux
programs that act on then, e.g. Asterisk and derived PBX software has
ISDN support which is actively used.

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

Tetsui wrote:

> This might be a mm problem. Please send to linux...@kvack.org .
>
> Before doing so, please identify line number using
>
>  $ addr2line -i -e /path/to/vmlinux c0097288
>
> etc. if built with CONFIG_DEBUG_INFO=y.
> (If CONFIG_DEBUG_INFO=n, please rebuild with CONFIG_DEBUG_INFO=y and try to 
> reproduce.)

thanks for this hint.

- I have recompiled it with CONFIG_DEBUG_INFO.
- while at it, I switched from 4.4.3 to 4.4.4
- this changed the address c0097288 to c00972ec.
- addr2line says it's in linux-4.4/mm/page_alloc.c:1792

1790: static struct page *__rmqueue(struct zone *zone, unsigned int order,
1791: int migratetype, gfp_t gfp_flags)
1792: {
1793: struct page *page;

So I did an "arm-linux-gnueabihf-objdump -Sgd linux/vmlinux", not sure
if that helps:

c00972ec <__rmqueue>:
 * Do the hard work of removing an element from the buddy allocator.
 * Call me with the zone->lock already held.
 */
static struct page *__rmqueue(struct zone *zone, unsigned int order,
int migratetype, gfp_t gfp_flags)
{
c00972ec:   e1a0c00dmov ip, sp
c00972f0:   e92ddff0push{r4, r5, r6, r7, r8, r9, sl, fp, ip, 
lr, pc}
c00972f4:   e24cb004sub fp, ip, #4
c00972f8:   e24dd024sub sp, sp, #36 ; 0x24
unsigned int current_order;
struct free_area *area;
struct page *page;

/* Find a page of the appropriate size in the preferred list */
for (current_order = order; current_order < MAX_ORDER; ++current_order) 
{
c00972fc:   e351000acmp r1, #10
 * Do the hard work of removing an element from the buddy allocator.
 * Call me with the zone->lock already held.
 */



Here's the new backtrace:

root@ptxc:~# stress-ng --sock 5
stress-ng: info: [374] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 10 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = eeb64000
[0104] *pgd=3c596831, *pte=, *ppte=
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep smsc95xx usbhid usbnet mii imx_sdma flexcan btusb btrtl 
btbcm btintel bluetooth
CPU: 1 PID: 378 Comm: stress-ng-socke Not tainted 4.4.4 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ee907300 ti: eebc task.ti: eebc
PC is at __rmqueue+0x74/0x308
LR is at 0x3
pc : []lr : [<0003>]psr: 60030093
sp : eebc1c00  ip : 0200  fp : eebc1c4c
r10: efd85114  r9 : 0008  r8 : 
r7 : 0003  r6 :   r5 : c050d068  r4 : 0100
r3 : c05d03ac  r2 : 006c  r1 : 0200  r0 : 0100
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3eb6404a  DAC: 0051
Process stress-ng-socke (pid: 378, stack limit = 0xeebc0210)
Stack: (0xeebc1c00 to 0xeebc2000)
1c00: 60030113 ef7b6b54 c05d0e09 c05ade00 0003 c05d02c0 c043ab20 c05ade00
1c20: 20030013 eebc1d54 c050d068 c050d054 c050d054 32ea424b 0008 c05d02c0
1c40: eebc1ce4 eebc1c50 c0097d18 c00972f8 0141 0002bbd2 ef7bc380 0018
1c60: c05d0d40 c05b2100 17f9 c043abb0 000a c05d39c0  c05b2080
1c80: 0100 c05d04d0 c05d0d48 c05d03e8 c05d0e55 0128 0141 020252c0
1ca0:  fff8  eebc1d54 60030013 0003 c0061cb8 020052c0
1cc0: 0003 c05d0d40 5580 32ea424b eebc1e84  eebc1d9c eebc1ce8
1ce0: c00980e8 c0097600 eebc1d1c 80100010 c0009440 c005da78 c01d4fa0 20030013
1d00:  eebc1d54 ee30ed80 ee18f380 eebc1d84 eebc1d20 c03ee8e4 c03ec7d0
1d20: eeb976e0 ef001c00  024102c0  000346db c05b2100 
1d40: 0002 ee18f714 0005   c05d0d40  c05d02c0
1d60:     eebc1e84 ee9077b4 024000c0 1180
1d80: 5580 32ea424b eebc1e84  eebc1db4 eebc1da0 c0389d74 c009801c
1da0: ee18f380 ee18f380 eebc1dcc eebc1db8 c0389dec c0389d10 ee37e180 ee18f380
1dc0: eebc1e4c eebc1dd0 c03e1f9c c0389ddc 5580 0001 21bd7366 3590
1de0: 0001 eebc1e8c c05b2bb4 eebc 0001  ee9077b4 
1e00: 0001 ee18f438 5580 08d0 c04357e8 5580 7fff 6ea3
1e20: eebc1eb4 ee18f380    edd370c0 eebc 
1e40: eebc1e6c eebc1e50 c04087fc c03e1dc8 edfc1ea0 ee18f380 eebc1eec 
1e60: eebc1e7c eebc1e70 c0385ea8 c0408774 eebc1ed4 eebc1e80 c0385f44 c0385e98
1e80: c00e62b4   0001 08d0 1180 eebc1ee4 0001
1ea0:    eebc1f00  edd370c0 eebc1f80 
1ec0:  c000fae4 eebc1f3c eebc1ed8 c00c9b90 c0385ec4 1a50 0004
1ee0: eebc1f1c bef549bc 1a50 0001  1a50 eebc1ee4 0001
1f00: edd370c0       

Re: 4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

Tetsui wrote:

> This might be a mm problem. Please send to linux...@kvack.org .
>
> Before doing so, please identify line number using
>
>  $ addr2line -i -e /path/to/vmlinux c0097288
>
> etc. if built with CONFIG_DEBUG_INFO=y.
> (If CONFIG_DEBUG_INFO=n, please rebuild with CONFIG_DEBUG_INFO=y and try to 
> reproduce.)

thanks for this hint.

- I have recompiled it with CONFIG_DEBUG_INFO.
- while at it, I switched from 4.4.3 to 4.4.4
- this changed the address c0097288 to c00972ec.
- addr2line says it's in linux-4.4/mm/page_alloc.c:1792

1790: static struct page *__rmqueue(struct zone *zone, unsigned int order,
1791: int migratetype, gfp_t gfp_flags)
1792: {
1793: struct page *page;

So I did an "arm-linux-gnueabihf-objdump -Sgd linux/vmlinux", not sure
if that helps:

c00972ec <__rmqueue>:
 * Do the hard work of removing an element from the buddy allocator.
 * Call me with the zone->lock already held.
 */
static struct page *__rmqueue(struct zone *zone, unsigned int order,
int migratetype, gfp_t gfp_flags)
{
c00972ec:   e1a0c00dmov ip, sp
c00972f0:   e92ddff0push{r4, r5, r6, r7, r8, r9, sl, fp, ip, 
lr, pc}
c00972f4:   e24cb004sub fp, ip, #4
c00972f8:   e24dd024sub sp, sp, #36 ; 0x24
unsigned int current_order;
struct free_area *area;
struct page *page;

/* Find a page of the appropriate size in the preferred list */
for (current_order = order; current_order < MAX_ORDER; ++current_order) 
{
c00972fc:   e351000acmp r1, #10
 * Do the hard work of removing an element from the buddy allocator.
 * Call me with the zone->lock already held.
 */



Here's the new backtrace:

root@ptxc:~# stress-ng --sock 5
stress-ng: info: [374] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 10 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = eeb64000
[0104] *pgd=3c596831, *pte=, *ppte=
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep smsc95xx usbhid usbnet mii imx_sdma flexcan btusb btrtl 
btbcm btintel bluetooth
CPU: 1 PID: 378 Comm: stress-ng-socke Not tainted 4.4.4 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ee907300 ti: eebc task.ti: eebc
PC is at __rmqueue+0x74/0x308
LR is at 0x3
pc : []lr : [<0003>]psr: 60030093
sp : eebc1c00  ip : 0200  fp : eebc1c4c
r10: efd85114  r9 : 0008  r8 : 
r7 : 0003  r6 :   r5 : c050d068  r4 : 0100
r3 : c05d03ac  r2 : 006c  r1 : 0200  r0 : 0100
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3eb6404a  DAC: 0051
Process stress-ng-socke (pid: 378, stack limit = 0xeebc0210)
Stack: (0xeebc1c00 to 0xeebc2000)
1c00: 60030113 ef7b6b54 c05d0e09 c05ade00 0003 c05d02c0 c043ab20 c05ade00
1c20: 20030013 eebc1d54 c050d068 c050d054 c050d054 32ea424b 0008 c05d02c0
1c40: eebc1ce4 eebc1c50 c0097d18 c00972f8 0141 0002bbd2 ef7bc380 0018
1c60: c05d0d40 c05b2100 17f9 c043abb0 000a c05d39c0  c05b2080
1c80: 0100 c05d04d0 c05d0d48 c05d03e8 c05d0e55 0128 0141 020252c0
1ca0:  fff8  eebc1d54 60030013 0003 c0061cb8 020052c0
1cc0: 0003 c05d0d40 5580 32ea424b eebc1e84  eebc1d9c eebc1ce8
1ce0: c00980e8 c0097600 eebc1d1c 80100010 c0009440 c005da78 c01d4fa0 20030013
1d00:  eebc1d54 ee30ed80 ee18f380 eebc1d84 eebc1d20 c03ee8e4 c03ec7d0
1d20: eeb976e0 ef001c00  024102c0  000346db c05b2100 
1d40: 0002 ee18f714 0005   c05d0d40  c05d02c0
1d60:     eebc1e84 ee9077b4 024000c0 1180
1d80: 5580 32ea424b eebc1e84  eebc1db4 eebc1da0 c0389d74 c009801c
1da0: ee18f380 ee18f380 eebc1dcc eebc1db8 c0389dec c0389d10 ee37e180 ee18f380
1dc0: eebc1e4c eebc1dd0 c03e1f9c c0389ddc 5580 0001 21bd7366 3590
1de0: 0001 eebc1e8c c05b2bb4 eebc 0001  ee9077b4 
1e00: 0001 ee18f438 5580 08d0 c04357e8 5580 7fff 6ea3
1e20: eebc1eb4 ee18f380    edd370c0 eebc 
1e40: eebc1e6c eebc1e50 c04087fc c03e1dc8 edfc1ea0 ee18f380 eebc1eec 
1e60: eebc1e7c eebc1e70 c0385ea8 c0408774 eebc1ed4 eebc1e80 c0385f44 c0385e98
1e80: c00e62b4   0001 08d0 1180 eebc1ee4 0001
1ea0:    eebc1f00  edd370c0 eebc1f80 
1ec0:  c000fae4 eebc1f3c eebc1ed8 c00c9b90 c0385ec4 1a50 0004
1ee0: eebc1f1c bef549bc 1a50 0001  1a50 eebc1ee4 0001
1f00: edd370c0       

4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

Hi,

on my system I can reproduce reliably a kernel OOPS when I run stress-ng
("apt-get install stress-ng"). Any help on how to track this down would
be appreciated, networking code is outside of my comfort zone (I'm just
a dilettante at device drivers ...).

It takes only a minute or two to get the OOPS:

root@ptxc:~# stress-ng --sock 5
stress-ng: info: [361] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 5 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = ee0d8000
[0104] *pgd=3e17c831, *pte=, *ppte=
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep smsc95xx usbnet mii usbhid imx_sdma flexcan btusb btrtl 
btbcm btintel bluetooth
CPU: 2 PID: 362 Comm: stress-ng-socke Not tainted 4.4.3 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: eeb30a00 ti: eea0a000 task.ti: eea0a000
PC is at __rmqueue+0x74/0x308
LR is at 0x3
pc : []lr : [<0003>]psr: 60030093
sp : eea0bc08  ip : 0200  fp : eea0bc54
r10: efd80b14  r9 : 0008  r8 : 
r7 : 0003  r6 :   r5 : c050bff8  r4 : 0100
r3 : c05ce36c  r2 : 006c  r1 : 0200  r0 : 0100
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3e0d804a  DAC: 0051
Process stress-ng-socke (pid: 362, stack limit = 0xeea0a210)
Stack: (0xeea0bc08 to 0xeea0c000)
bc00:    c05ca780 ed93dd80 ed93dd80 eea0bc5c c05ce280
bc20: c03d5838 c03d3b00 c05b04f8 eea0bd5c c050bff8 c050bfe4 c050bfe4 ed93de38
bc40: 0008 c05ce280 eea0bcec eea0bc58 c0097cb4 c0097294 0141 0002c26d
bc60: c03d59c4 0018 c05ced00 c05b0100 acd4 c0439bb0 000a c05d19c0
bc80:  c05b0080 0100 c05ce490 c05ced08 c05ce3a8 c05cee15 0128
bca0: 0141 020252c0  fff8  eea0bd5c 60030013 0003
bcc0: eea0bcf4 020052c0 0003 c05ced00 ffcb ed93de38 eea0be84 
bce0: eea0bda4 eea0bcf0 c0098084 c009759c c006caf8 80100010 0fcfc2fc 40030013
bd00: eea0bd24 ed93dd80 ed93dd80 0004 ed999e00 ed93dd80 eea0bd8c eea0bd28
bd20: c03ee130 c03ebcac 0002 ef001c00  024102c0  000346db
bd40: c05b0100  0002 ed93e114 0005   c05ced00
bd60:  c05ce280     eea0be84 eeb30eb4
bd80: 024000c0 05d0 ffcb ed93de38 eea0be84  eea0bdbc eea0bda8
bda0: c0389650 c0097fb8 ed93dd80 ed93dd80 eea0bdd4 eea0bdc0 c03896c8 c03895ec
bdc0: ed999e00 ed93dd80 eea0be4c eea0bdd8 c03e14d4 c03896b8 ffcb 0014
bde0: 14bf 0001 eeb30eb4 0001 0001  eea0a018 
be00: eeb30eb4 0001 ffcb 0560 c0434ca8 ffcb 7fff 7fff
be20: ed958000 ed93dd80    eea6c000 eea0a000 
be40: eea0be6c eea0be50 c0407cbc c03e131c ee98c1a0 ed93dd80 eea0beec 
be60: eea0be7c eea0be70 c0385784 c0407c34 eea0bed4 eea0be80 c0385820 c0385774
be80: c00e6220   0001 0560 05d0 eea0bee4 0001
bea0:    eea0bf00  eea6c000 eea0bf80 
bec0:  c000fae4 eea0bf3c eea0bed8 c00c9b2c c03857a0 0b30 0004
bee0: eea0bf1c bea359bc 0b30 0001  0b30 eea0bee4 0001
bf00: eea6c000       
bf20: eea6c000 0b30 bea359bc eea0bf80 eea0bf4c eea0bf40 c00c9b84 c00c9ab0
bf40: eea0bf7c eea0bf50 c00ca330 c00c9b5c   eea0bf7c eea6c000
bf60: eea6c000 0b30 bea359bc c000fae4 eea0bfa4 eea0bf80 c00cac0c c00ca2a4
bf80:   0004 0002a1e8 b6f6f140 0004  eea0bfa8
bfa0: c000f920 c00cabcc 0004 0002a1e8 0004 bea359bc 0b30 bea379bc
bfc0: 0004 0002a1e8 b6f6f140 0004 0b30 016f 0002a1f0 0003
bfe0:  bea358f4 00014a57 b6eaa4d6 40030030 0004  
Backtrace: 
[] (__rmqueue) from [] (get_page_from_freelist+0x724/0x914)
 r10:c05ce280 r9:0008 r8:ed93de38 r7:c050bfe4 r6:c050bfe4 r5:c050bff8
 r4:eea0bd5c
[] (get_page_from_freelist) from [] 
(__alloc_pages_nodemask+0xd8/0x898)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:c05ced00 r5:0003
 r4:020052c0
[] (__alloc_pages_nodemask) from [] 
(skb_page_frag_refill+0x70/0xcc)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:05d0 r5:024000c0
 r4:eeb30eb4
[] (skb_page_frag_refill) from [] 
(sk_page_frag_refill+0x1c/0x74)
 r5:ed93dd80 r4:ed93dd80
[] (sk_page_frag_refill) from [] (tcp_sendmsg+0x1c4/0xa58)
 r5:ed93dd80 r4:ed999e00
[] (tcp_sendmsg) from [] (inet_sendmsg+0x94/0xc8)
 r10: r9:eea0a000 r8:eea6c000 r7: r6: r5:
 r4:ed93dd80
[] (inet_sendmsg) from [] (sock_sendmsg+0x1c/0x2c)
 r5: r4:eea0beec
[] (sock_sendmsg) from [] (sock_write_iter+0x8c/0xc0)
[] 

4.4.3: OOPS when running "stress-ng --sock 5"

[Holger Schurig]

Hi,

on my system I can reproduce reliably a kernel OOPS when I run stress-ng
("apt-get install stress-ng"). Any help on how to track this down would
be appreciated, networking code is outside of my comfort zone (I'm just
a dilettante at device drivers ...).

It takes only a minute or two to get the OOPS:

root@ptxc:~# stress-ng --sock 5
stress-ng: info: [361] dispatching hogs: 0 I/O-Sync, 0 CPU, 0 VM-mmap, 0 
HDD-Write, 0 Fork, 0 Context-switch, 0 Pipe, 0 Cache, 5 Socket, 0 Yield, 0 
Fallocate, 0 Flock, 0 Affinity, 0 Timer, 0 Dentry, 0 Urandom, 0 Float, 0 Int, 0 
Semaphore, 0 Open, 0 SigQueue, 0 Poll
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = ee0d8000
[0104] *pgd=3e17c831, *pte=, *ppte=
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in: bnep smsc95xx usbnet mii usbhid imx_sdma flexcan btusb btrtl 
btbcm btintel bluetooth
CPU: 2 PID: 362 Comm: stress-ng-socke Not tainted 4.4.3 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: eeb30a00 ti: eea0a000 task.ti: eea0a000
PC is at __rmqueue+0x74/0x308
LR is at 0x3
pc : []lr : [<0003>]psr: 60030093
sp : eea0bc08  ip : 0200  fp : eea0bc54
r10: efd80b14  r9 : 0008  r8 : 
r7 : 0003  r6 :   r5 : c050bff8  r4 : 0100
r3 : c05ce36c  r2 : 006c  r1 : 0200  r0 : 0100
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3e0d804a  DAC: 0051
Process stress-ng-socke (pid: 362, stack limit = 0xeea0a210)
Stack: (0xeea0bc08 to 0xeea0c000)
bc00:    c05ca780 ed93dd80 ed93dd80 eea0bc5c c05ce280
bc20: c03d5838 c03d3b00 c05b04f8 eea0bd5c c050bff8 c050bfe4 c050bfe4 ed93de38
bc40: 0008 c05ce280 eea0bcec eea0bc58 c0097cb4 c0097294 0141 0002c26d
bc60: c03d59c4 0018 c05ced00 c05b0100 acd4 c0439bb0 000a c05d19c0
bc80:  c05b0080 0100 c05ce490 c05ced08 c05ce3a8 c05cee15 0128
bca0: 0141 020252c0  fff8  eea0bd5c 60030013 0003
bcc0: eea0bcf4 020052c0 0003 c05ced00 ffcb ed93de38 eea0be84 
bce0: eea0bda4 eea0bcf0 c0098084 c009759c c006caf8 80100010 0fcfc2fc 40030013
bd00: eea0bd24 ed93dd80 ed93dd80 0004 ed999e00 ed93dd80 eea0bd8c eea0bd28
bd20: c03ee130 c03ebcac 0002 ef001c00  024102c0  000346db
bd40: c05b0100  0002 ed93e114 0005   c05ced00
bd60:  c05ce280     eea0be84 eeb30eb4
bd80: 024000c0 05d0 ffcb ed93de38 eea0be84  eea0bdbc eea0bda8
bda0: c0389650 c0097fb8 ed93dd80 ed93dd80 eea0bdd4 eea0bdc0 c03896c8 c03895ec
bdc0: ed999e00 ed93dd80 eea0be4c eea0bdd8 c03e14d4 c03896b8 ffcb 0014
bde0: 14bf 0001 eeb30eb4 0001 0001  eea0a018 
be00: eeb30eb4 0001 ffcb 0560 c0434ca8 ffcb 7fff 7fff
be20: ed958000 ed93dd80    eea6c000 eea0a000 
be40: eea0be6c eea0be50 c0407cbc c03e131c ee98c1a0 ed93dd80 eea0beec 
be60: eea0be7c eea0be70 c0385784 c0407c34 eea0bed4 eea0be80 c0385820 c0385774
be80: c00e6220   0001 0560 05d0 eea0bee4 0001
bea0:    eea0bf00  eea6c000 eea0bf80 
bec0:  c000fae4 eea0bf3c eea0bed8 c00c9b2c c03857a0 0b30 0004
bee0: eea0bf1c bea359bc 0b30 0001  0b30 eea0bee4 0001
bf00: eea6c000       
bf20: eea6c000 0b30 bea359bc eea0bf80 eea0bf4c eea0bf40 c00c9b84 c00c9ab0
bf40: eea0bf7c eea0bf50 c00ca330 c00c9b5c   eea0bf7c eea6c000
bf60: eea6c000 0b30 bea359bc c000fae4 eea0bfa4 eea0bf80 c00cac0c c00ca2a4
bf80:   0004 0002a1e8 b6f6f140 0004  eea0bfa8
bfa0: c000f920 c00cabcc 0004 0002a1e8 0004 bea359bc 0b30 bea379bc
bfc0: 0004 0002a1e8 b6f6f140 0004 0b30 016f 0002a1f0 0003
bfe0:  bea358f4 00014a57 b6eaa4d6 40030030 0004  
Backtrace: 
[] (__rmqueue) from [] (get_page_from_freelist+0x724/0x914)
 r10:c05ce280 r9:0008 r8:ed93de38 r7:c050bfe4 r6:c050bfe4 r5:c050bff8
 r4:eea0bd5c
[] (get_page_from_freelist) from [] 
(__alloc_pages_nodemask+0xd8/0x898)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:c05ced00 r5:0003
 r4:020052c0
[] (__alloc_pages_nodemask) from [] 
(skb_page_frag_refill+0x70/0xcc)
 r10: r9:eea0be84 r8:ed93de38 r7:ffcb r6:05d0 r5:024000c0
 r4:eeb30eb4
[] (skb_page_frag_refill) from [] 
(sk_page_frag_refill+0x1c/0x74)
 r5:ed93dd80 r4:ed93dd80
[] (sk_page_frag_refill) from [] (tcp_sendmsg+0x1c4/0xa58)
 r5:ed93dd80 r4:ed999e00
[] (tcp_sendmsg) from [] (inet_sendmsg+0x94/0xc8)
 r10: r9:eea0a000 r8:eea6c000 r7: r6: r5:
 r4:ed93dd80
[] (inet_sendmsg) from [] (sock_sendmsg+0x1c/0x2c)
 r5: r4:eea0beec
[] (sock_sendmsg) from [] (sock_write_iter+0x8c/0xc0)
[] 

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Holger Schurig]

Krzysztof Kozlowski  writes:

> + depends on HAS_IOMEM# For MFD_SYSCON


I think this comment is not necessary, it's also highly unusual. On
other words: other patches like this don't add such comments.

You can always use "git blame" to find out why some line has changed the
way it changed ...

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Holger Schurig]

Krzysztof Kozlowski  writes:

> + depends on HAS_IOMEM# For MFD_SYSCON


I think this comment is not necessary, it's also highly unusual. On
other words: other patches like this don't add such comments.

You can always use "git blame" to find out why some line has changed the
way it changed ...

Re: [RFC v1] clk: Add debugfs nodes for enable/disable/set-rate/set-parent

[Holger Schurig]

Pankaj DEV  writes:

> The prime motive for clk_set_rate is to set new rate for a clock,
> since the 'clk_rate' currently available, allows only reading.
> To provide reading rate from 'clk_set_rate' is just additional feature.

Sure.

But my point is to combine things.


After your patch:

- read via clk_rate
- read via clk_set_rate
- write via clk_set_rate

My proposal:

- read via clk_rate
- write via clk_rate

Re: [RFC v1] clk: Add debugfs nodes for enable/disable/set-rate/set-parent

[Holger Schurig]

Pankaj DEV  writes:

> The prime motive for clk_set_rate is to set new rate for a clock,
> since the 'clk_rate' currently available, allows only reading.
> To provide reading rate from 'clk_set_rate' is just additional feature.

Sure.

But my point is to combine things.


After your patch:

- read via clk_rate
- read via clk_set_rate
- write via clk_set_rate

My proposal:

- read via clk_rate
- write via clk_rate

Re: [RFC v1] clk: Add debugfs nodes for enable/disable/set-rate/set-parent

[Holger Schurig]

Pankaj Dev  writes:

> 1. clk_set_rate : Set new rate to value. Reading returns the
> current rate

If you can use this to set *and* read it, then "_set_" shouldn't be in
the name.

What is wrong with using the existing "clk_rate" for reading/setting the
rate?

Re: [RFC v1] clk: Add debugfs nodes for enable/disable/set-rate/set-parent

[Holger Schurig]

Pankaj Dev  writes:

> 1. clk_set_rate : Set new rate to value. Reading returns the
> current rate

If you can use this to set *and* read it, then "_set_" shouldn't be in
the name.

What is wrong with using the existing "clk_rate" for reading/setting the
rate?

weird RCU problem with 4.4.0

[Holger Schurig]

Hi,

in the dmesg log (actually "journalctl -f") of one of my machines I had this:

...
03:25:01 CRON[16607]: pam_unix(cron:session): session closed for user root
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=301
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=301
(detected by 0, t=303 jiffies, g=2533688, c=2533687, q=4860)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=1204
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=1205
(detected by 0, t=1208 jiffies, g=2533688, c=2533687, q=19822)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=2109
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=2109
(detected by 0, t=2113 jiffies, g=2533688, c=2533687, q=34248)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=3011
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=3011
(detected by 0, t=3018 jiffies, g=2533688, c=2533687, q=48662)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=3912
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=3912
(detected by 0, t=3923 jiffies, g=2533688, c=2533687, q=63080)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=4815
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=4815
(detected by 0, t=4828 jiffies, g=2533688, c=2533687, q=68037)
...
and so on, and so forth ...
...
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=137745
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=137746
(detected by 0, t=137863 jiffies, g=2533688, c=2533687, q=68849)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=138651
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=138652

[4.4, OOPS]: kernel oops around __wake_up_common / __sys_recvmsg

[Holger Schurig]

Hi all,

I (still) have a problem with 4.4.0 having lookups and oopsing. This
happens not instantly: when I run some test program *) on 10 machines, at
the next morning 6-8 have this issue.

Via the serial port I catch the output of "journalctl -f" and get this:

...
06:35:01 CRON[27050]: pam_unix(cron:session): session closed for user root
Unable to handle kernel paging request at virtual address fffe
pgd = ee2f4000
[fffe] *pgd=3fffd861, *pte=, *ppte=
Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
Modules linked in: bnep smsc95xx usbnet mii btusb btrtl btbcm btintel bluetooth 
imx_sdma flexcan dlog(O)
CPU: 3 PID: 331 Comm: Xorg Tainted: G   O4.4.0 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ee12e3c0 ti: ed996000 task.ti: ed996000
PC is at 0xfffe
LR is at __wake_up_common+0x50/0x7c
pc : []lr : []psr: 200100b3
sp : ed997c68  ip :   fp : ed997c8c
r10:   r9 : c0037a38  r8 : 0001
r7 : 0001  r6 : 0001  r5 : ee09ad44  r4 : fff3
r3 : 0304  r2 : 0001  r1 : 0001  r0 : ee15fd18
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  Segment none
Control: 10c5387d  Table: 3e2f404a  DAC: 0051
Process Xorg (pid: 331, stack limit = 0xed996210)
Stack: (0xed997c68 to 0xed998000)
7c60:   ee09ad40 a0010013 0001 0001 0304 0010
7c80: ed997cbc ed997c90 c005084c c0050214 0304 80150011 c00cfb18 eea1d900
7ca0: eea1d9ac eea1d5e4 ee0d2600 ed997df4 ed997cd4 ed997cc0 c03cd0dc c005080c
7cc0: c03cd05c eea1d900 ed997cec ed997cd8 c0344e08 c03cd068 ee0d2600 ffa1
7ce0: ed997d1c ed997cf0 c03cc9b8 c0344dc8 0010   
7d00:   c034c4a8 ee0d2600 ed997d34 ed997d20 c0345ed0 c03cc958
7d20: 0001 ee0d2600 ed997d4c ed997d38 c0346004 c0345e6c 0001 eea1d400
7d40: ed997d5c ed997d50 c0346174 c0345ffc ed997dec ed997d60 c03cdbc0 c0346128
7d60: ed997d8c ed997d70 c0042bc0 0010   eea1d5bc ecda7b00
7d80:  eea1d464 0001  0ff0 0010  
7da0:     0008 c00c06a4 0008 ed997f54
7dc0: ed997e40 0040 1000 ed997f4c ecda7b00 bed92988 ed997e88 ecda7b00
7de0: ed997e2c ed997df0 c03cde00 c03cd60c ed997f54 c03cc7d8 ecda7b00 ed997f4c
7e00:  1000 0040  ecda7b00 ed997f4c bed9296c 0040
7e20: ed997e3c ed997e30 c033ea58 c03cddbc ed997f34 ed997e40 c0340774 c033ea4c
7e40:   8013c508 1000 ef7ceb54 ef7cebf8 ed997e94 ed997e68
7e60: c0072fd4 c0014e98 291b24af e16e ed997ebc ef7d43c0  294a9002
7e80: e16e ef7cebb8 ed997ebc ed997e98 c0074eb8 c0072eac  
7ea0:  7fff ef7ceb40 ef7cebd8 ed997f14 ed997ec0 c006801c c0074e40
7ec0: ef7cebf8 c0550b40 294a9002 e16e 291adbc5 e16e 0003 
7ee0: 294a9002 e16e 0040 0001 ef005c00 c0563600 ef01ecc0 0010
7f00: ed997f1c ed997f10 c00d8ae0 ecda7b00  bed9296c 0129 c000f2e4
7f20: ed996000  ed997f94 ed997f38 c03414f8 c03406e8  7f6d0348
7f40: 0107  fff7    0010 0ff0
7f60: ed997e48 0001 bed92988 020c   0008 bed92988
7f80: 8013b3f0 b6f42f10 ed997fa4 ed997f98 c034152c c03414c0  ed997fa8
7fa0: c000f120 c0341528 bed92988 8013b3f0 000b bed9296c  cedd7c00
7fc0: bed92988 8013b3f0 b6f42f10 0129 bed9296c 1000 8013c508 
7fe0:  bed92954 7f685a79 b6c2dbd6 60010030 000b 3fffd861 3fffdc61
Backtrace:
[] (__wake_up_common) from [] (__wake_up_sync_key+0x4c/0x60)
 r9:0010 r8:0304 r7:0001 r6:0001 r5:a0010013 r4:ee09ad40
[] (__wake_up_sync_key) from [] (unix_write_space+0x80/0x88)
 r8:ed997df4 r7:ee0d2600 r6:eea1d5e4 r5:eea1d9ac r4:eea1d900
[] (unix_write_space) from [] (sock_wfree+0x4c/0x84)
 r4:eea1d900 r3:c03cd05c
[] (sock_wfree) from [] (unix_destruct_scm+0x6c/0x74)
 r5:ffa1 r4:ee0d2600
[] (unix_destruct_scm) from [] 
(skb_release_head_state+0x70/0xb0)
 r4:ee0d2600
[] (skb_release_head_state) from [] (__kfree_skb+0x14/0xa8)
 r4:ee0d2600 r3:0001
[] (__kfree_skb) from [] (consume_skb+0x58/0x5c)
 r4:eea1d400 r3:0001
[] (consume_skb) from [] 
(unix_stream_read_generic+0x5c0/0x720)
[] (unix_stream_read_generic) from [] 
(unix_stream_recvmsg+0x50/0x5c)
 r10:ecda7b00 r9:ed997e88 r8:bed92988 r7:ecda7b00 r6:ed997f4c r5:1000
 r4:0040
[] (unix_stream_recvmsg) from [] (sock_recvmsg+0x18/0x1c)
 r7:0040 r6:bed9296c r5:ed997f4c r4:ecda7b00
[] (sock_recvmsg) from [] (___sys_recvmsg+0x98/0x16c)
[] (___sys_recvmsg) from [] (__sys_recvmsg+0x44/0x68)
 r10: r9:ed996000 r8:c000f2e4 r7:0129 r6:bed9296c r5:
 r4:ecda7b00
[] (__sys_recvmsg) from [] (SyS_recvmsg+0x10/0x14)
 r6:b6f42f10 r5:8013b3f0 r4:bed92988
[] (SyS_recvmsg) from [] (ret_fast_syscall+0x0/0x3c)
Code: bad PC value
---[ end trace 2c00262b7dd79d60 ]---
note: Xorg[331] exited with preempt_count 1

weird RCU problem with 4.4.0

[Holger Schurig]

Hi,

in the dmesg log (actually "journalctl -f") of one of my machines I had this:

...
03:25:01 CRON[16607]: pam_unix(cron:session): session closed for user root
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=301
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=301
(detected by 0, t=303 jiffies, g=2533688, c=2533687, q=4860)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=1204
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=1205
(detected by 0, t=1208 jiffies, g=2533688, c=2533687, q=19822)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=2109
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=2109
(detected by 0, t=2113 jiffies, g=2533688, c=2533687, q=34248)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=3011
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=3011
(detected by 0, t=3018 jiffies, g=2533688, c=2533687, q=48662)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=3912
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=3912
(detected by 0, t=3923 jiffies, g=2533688, c=2533687, q=63080)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=4815
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=4815
(detected by 0, t=4828 jiffies, g=2533688, c=2533687, q=68037)
...
and so on, and so forth ...
...
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=137745
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=137746
(detected by 0, t=137863 jiffies, g=2533688, c=2533687, q=68849)
INFO: rcu_preempt detected stalls on CPUs/tasks:
1-...: (1 GPs behind) idle=763/140/0 softirq=6109762/6109762 
fqs=138651
2-...: (1 GPs behind) idle=2f3/140/0 softirq=5129036/5129037 
fqs=138652

[4.4, OOPS]: kernel oops around __wake_up_common / __sys_recvmsg

[Holger Schurig]

Hi all,

I (still) have a problem with 4.4.0 having lookups and oopsing. This
happens not instantly: when I run some test program *) on 10 machines, at
the next morning 6-8 have this issue.

Via the serial port I catch the output of "journalctl -f" and get this:

...
06:35:01 CRON[27050]: pam_unix(cron:session): session closed for user root
Unable to handle kernel paging request at virtual address fffe
pgd = ee2f4000
[fffe] *pgd=3fffd861, *pte=, *ppte=
Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
Modules linked in: bnep smsc95xx usbnet mii btusb btrtl btbcm btintel bluetooth 
imx_sdma flexcan dlog(O)
CPU: 3 PID: 331 Comm: Xorg Tainted: G   O4.4.0 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ee12e3c0 ti: ed996000 task.ti: ed996000
PC is at 0xfffe
LR is at __wake_up_common+0x50/0x7c
pc : []lr : []psr: 200100b3
sp : ed997c68  ip :   fp : ed997c8c
r10:   r9 : c0037a38  r8 : 0001
r7 : 0001  r6 : 0001  r5 : ee09ad44  r4 : fff3
r3 : 0304  r2 : 0001  r1 : 0001  r0 : ee15fd18
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  Segment none
Control: 10c5387d  Table: 3e2f404a  DAC: 0051
Process Xorg (pid: 331, stack limit = 0xed996210)
Stack: (0xed997c68 to 0xed998000)
7c60:   ee09ad40 a0010013 0001 0001 0304 0010
7c80: ed997cbc ed997c90 c005084c c0050214 0304 80150011 c00cfb18 eea1d900
7ca0: eea1d9ac eea1d5e4 ee0d2600 ed997df4 ed997cd4 ed997cc0 c03cd0dc c005080c
7cc0: c03cd05c eea1d900 ed997cec ed997cd8 c0344e08 c03cd068 ee0d2600 ffa1
7ce0: ed997d1c ed997cf0 c03cc9b8 c0344dc8 0010   
7d00:   c034c4a8 ee0d2600 ed997d34 ed997d20 c0345ed0 c03cc958
7d20: 0001 ee0d2600 ed997d4c ed997d38 c0346004 c0345e6c 0001 eea1d400
7d40: ed997d5c ed997d50 c0346174 c0345ffc ed997dec ed997d60 c03cdbc0 c0346128
7d60: ed997d8c ed997d70 c0042bc0 0010   eea1d5bc ecda7b00
7d80:  eea1d464 0001  0ff0 0010  
7da0:     0008 c00c06a4 0008 ed997f54
7dc0: ed997e40 0040 1000 ed997f4c ecda7b00 bed92988 ed997e88 ecda7b00
7de0: ed997e2c ed997df0 c03cde00 c03cd60c ed997f54 c03cc7d8 ecda7b00 ed997f4c
7e00:  1000 0040  ecda7b00 ed997f4c bed9296c 0040
7e20: ed997e3c ed997e30 c033ea58 c03cddbc ed997f34 ed997e40 c0340774 c033ea4c
7e40:   8013c508 1000 ef7ceb54 ef7cebf8 ed997e94 ed997e68
7e60: c0072fd4 c0014e98 291b24af e16e ed997ebc ef7d43c0  294a9002
7e80: e16e ef7cebb8 ed997ebc ed997e98 c0074eb8 c0072eac  
7ea0:  7fff ef7ceb40 ef7cebd8 ed997f14 ed997ec0 c006801c c0074e40
7ec0: ef7cebf8 c0550b40 294a9002 e16e 291adbc5 e16e 0003 
7ee0: 294a9002 e16e 0040 0001 ef005c00 c0563600 ef01ecc0 0010
7f00: ed997f1c ed997f10 c00d8ae0 ecda7b00  bed9296c 0129 c000f2e4
7f20: ed996000  ed997f94 ed997f38 c03414f8 c03406e8  7f6d0348
7f40: 0107  fff7    0010 0ff0
7f60: ed997e48 0001 bed92988 020c   0008 bed92988
7f80: 8013b3f0 b6f42f10 ed997fa4 ed997f98 c034152c c03414c0  ed997fa8
7fa0: c000f120 c0341528 bed92988 8013b3f0 000b bed9296c  cedd7c00
7fc0: bed92988 8013b3f0 b6f42f10 0129 bed9296c 1000 8013c508 
7fe0:  bed92954 7f685a79 b6c2dbd6 60010030 000b 3fffd861 3fffdc61
Backtrace:
[] (__wake_up_common) from [] (__wake_up_sync_key+0x4c/0x60)
 r9:0010 r8:0304 r7:0001 r6:0001 r5:a0010013 r4:ee09ad40
[] (__wake_up_sync_key) from [] (unix_write_space+0x80/0x88)
 r8:ed997df4 r7:ee0d2600 r6:eea1d5e4 r5:eea1d9ac r4:eea1d900
[] (unix_write_space) from [] (sock_wfree+0x4c/0x84)
 r4:eea1d900 r3:c03cd05c
[] (sock_wfree) from [] (unix_destruct_scm+0x6c/0x74)
 r5:ffa1 r4:ee0d2600
[] (unix_destruct_scm) from [] 
(skb_release_head_state+0x70/0xb0)
 r4:ee0d2600
[] (skb_release_head_state) from [] (__kfree_skb+0x14/0xa8)
 r4:ee0d2600 r3:0001
[] (__kfree_skb) from [] (consume_skb+0x58/0x5c)
 r4:eea1d400 r3:0001
[] (consume_skb) from [] 
(unix_stream_read_generic+0x5c0/0x720)
[] (unix_stream_read_generic) from [] 
(unix_stream_recvmsg+0x50/0x5c)
 r10:ecda7b00 r9:ed997e88 r8:bed92988 r7:ecda7b00 r6:ed997f4c r5:1000
 r4:0040
[] (unix_stream_recvmsg) from [] (sock_recvmsg+0x18/0x1c)
 r7:0040 r6:bed9296c r5:ed997f4c r4:ecda7b00
[] (sock_recvmsg) from [] (___sys_recvmsg+0x98/0x16c)
[] (___sys_recvmsg) from [] (__sys_recvmsg+0x44/0x68)
 r10: r9:ed996000 r8:c000f2e4 r7:0129 r6:bed9296c r5:
 r4:ecda7b00
[] (__sys_recvmsg) from [] (SyS_recvmsg+0x10/0x14)
 r6:b6f42f10 r5:8013b3f0 r4:bed92988
[] (SyS_recvmsg) from [] (ret_fast_syscall+0x0/0x3c)
Code: bad PC value
---[ end trace 2c00262b7dd79d60 ]---
note: Xorg[331] exited with preempt_count 1

Re: [RFC 0/6] mmc: Field Firmware Update

[Holger Schurig]

> Sorry for the delay.

No problem, I was busy with many other projects as well.

> My advise right now is to try this out via the mmc ioctl in userspace,
> yes. Although, if you encounter any issues with that approach that it
> might not be reliable, I am open to look into the in-kernel solution
> again.

I managed to update my Kingston eMMCs with a slighly modified patch to
what I submitted. I however didn't bother to submit this, as I saw no
chance of getting it applied.

Also I once asked in the mailing list if there is some user-space
example of how to use the multi-block feature that is supposed to enable
this, but I haven't gotten an answer.

> Regarding mmc-utils as where I recommend you to implement this, I have
> been thinking of moving this tool into the tools directory in the
> kernel.

Sounds good to me.



Remotely related:

Do you know that some google people made their own version of mmc-utils
for ChromeOS? And the don't seem to give much effort in unification of
them?  As if the world wouldn't know how hard it can be to re-unite
things again, Google should know from their custom kernels they use on
Android ...  Sigh.


So you can

* git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
* git clone https://chromium.googlesource.com/chromiumos/third_party/mmc-utils

currently.


--
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: [RFC 0/6] mmc: Field Firmware Update

[Holger Schurig]

> Sorry for the delay.

No problem, I was busy with many other projects as well.

> My advise right now is to try this out via the mmc ioctl in userspace,
> yes. Although, if you encounter any issues with that approach that it
> might not be reliable, I am open to look into the in-kernel solution
> again.

I managed to update my Kingston eMMCs with a slighly modified patch to
what I submitted. I however didn't bother to submit this, as I saw no
chance of getting it applied.

Also I once asked in the mailing list if there is some user-space
example of how to use the multi-block feature that is supposed to enable
this, but I haven't gotten an answer.

> Regarding mmc-utils as where I recommend you to implement this, I have
> been thinking of moving this tool into the tools directory in the
> kernel.

Sounds good to me.



Remotely related:

Do you know that some google people made their own version of mmc-utils
for ChromeOS? And the don't seem to give much effort in unification of
them?  As if the world wouldn't know how hard it can be to re-unite
things again, Google should know from their custom kernels they use on
Android ...  Sigh.


So you can

* git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
* git clone https://chromium.googlesource.com/chromiumos/third_party/mmc-utils

currently.


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

[PATCH 1/6] mmc: move mmc_prepare_mrq() to core.c

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

Signed-off-by: Holger Schurig 
---
 drivers/mmc/card/mmc_test.c | 48 -
 drivers/mmc/core/core.c | 41 ++
 include/linux/mmc/core.h|  4 
 3 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 7fc9174..69b6c45 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -184,46 +184,6 @@ static int mmc_test_set_blksize(struct mmc_test_card 
*test, unsigned size)
return mmc_set_blocklen(test->card, size);
 }
 
-/*
- * Fill in the mmc_request structure given a set of transfer parameters.
- */
-static void mmc_test_prepare_mrq(struct mmc_test_card *test,
-   struct mmc_request *mrq, struct scatterlist *sg, unsigned sg_len,
-   unsigned dev_addr, unsigned blocks, unsigned blksz, int write)
-{
-   BUG_ON(!mrq || !mrq->cmd || !mrq->data || !mrq->stop);
-
-   if (blocks > 1) {
-   mrq->cmd->opcode = write ?
-   MMC_WRITE_MULTIPLE_BLOCK : MMC_READ_MULTIPLE_BLOCK;
-   } else {
-   mrq->cmd->opcode = write ?
-   MMC_WRITE_BLOCK : MMC_READ_SINGLE_BLOCK;
-   }
-
-   mrq->cmd->arg = dev_addr;
-   if (!mmc_card_blockaddr(test->card))
-   mrq->cmd->arg <<= 9;
-
-   mrq->cmd->flags = MMC_RSP_R1 | MMC_CMD_ADTC;
-
-   if (blocks == 1)
-   mrq->stop = NULL;
-   else {
-   mrq->stop->opcode = MMC_STOP_TRANSMISSION;
-   mrq->stop->arg = 0;
-   mrq->stop->flags = MMC_RSP_R1B | MMC_CMD_AC;
-   }
-
-   mrq->data->blksz = blksz;
-   mrq->data->blocks = blocks;
-   mrq->data->flags = write ? MMC_DATA_WRITE : MMC_DATA_READ;
-   mrq->data->sg = sg;
-   mrq->data->sg_len = sg_len;
-
-   mmc_set_data_timeout(mrq->data, test->card);
-}
-
 static int mmc_test_busy(struct mmc_command *cmd)
 {
return !(cmd->resp[0] & R1_READY_FOR_DATA) ||
@@ -281,7 +241,7 @@ static int mmc_test_buffer_transfer(struct mmc_test_card 
*test,
 
sg_init_one(, buffer, blksz);
 
-   mmc_test_prepare_mrq(test, , , 1, addr, 1, blksz, write);
+   mmc_prepare_mrq(test->card, , , 1, addr, 1, blksz, write);
 
mmc_wait_for_req(test->card->host, );
 
@@ -805,7 +765,7 @@ static int mmc_test_nonblock_transfer(struct mmc_test_card 
*test,
other_areq->err_check = mmc_test_check_result_async;
 
for (i = 0; i < count; i++) {
-   mmc_test_prepare_mrq(test, cur_areq->mrq, sg, sg_len, dev_addr,
+   mmc_prepare_mrq(test->card, cur_areq->mrq, sg, sg_len, dev_addr,
 blocks, blksz, write);
done_areq = mmc_start_req(test->card->host, cur_areq, );
 
@@ -847,7 +807,7 @@ static int mmc_test_simple_transfer(struct mmc_test_card 
*test,
mrq.data = 
mrq.stop = 
 
-   mmc_test_prepare_mrq(test, , sg, sg_len, dev_addr,
+   mmc_prepare_mrq(test->card, , sg, sg_len, dev_addr,
blocks, blksz, write);
 
mmc_wait_for_req(test->card->host, );
@@ -876,7 +836,7 @@ static int mmc_test_broken_transfer(struct mmc_test_card 
*test,
 
sg_init_one(, test->buffer, blocks * blksz);
 
-   mmc_test_prepare_mrq(test, , , 1, 0, blocks, blksz, write);
+   mmc_prepare_mrq(test->card, , , 1, 0, blocks, blksz, write);
mmc_test_prepare_broken_mrq(test, , write);
 
mmc_wait_for_req(test->card->host, );
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5ae89e4..2b5e398 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2815,6 +2815,47 @@ int mmc_pm_notify(struct notifier_block *notify_block,
 }
 #endif
 
+/*
+ * Fill in the mmc_request structure given a set of transfer parameters.
+ */
+void mmc_prepare_mrq(struct mmc_card *card,
+   struct mmc_request *mrq, struct scatterlist *sg, unsigned sg_len,
+   unsigned dev_addr, unsigned blocks, unsigned blksz, int write)
+{
+   BUG_ON(!mrq || !mrq->cmd || !mrq->data || !mrq->stop);
+
+   if (blocks > 1) {
+   mrq->cmd->opcode = write ?
+   MMC_WRITE_MULTIPLE_BLOCK : MMC_READ_MULTIPLE_BLOCK;
+   } else {
+   mrq->cmd->opcode = write ?
+   MMC_WRITE_BLOCK : MMC_READ_SINGLE_BLOCK;
+   }
+
+   mrq->cmd->arg = dev_addr;
+   if (!mmc_card_blockaddr(card))
+   mrq->cmd->arg <<= 9;
+
+   mrq->cmd->flags = MMC_RSP_R1 | MMC_CMD_ADTC;
+
+   if (blocks == 1)
+  

[RFC 0/6] mmc: Field Firmware Update

[Holger Schurig]

There have been some attempts to add FFU (field firmware update).  The last
AFAIK in Nov 2014, http://www.spinics.net/lists/linux-mmc/msg29324.html

But it seems that the committers weren't persistent enought.

I took the liberty to take Avi's patch and make it hopefully
maintainer-review friendly.

The first 5 patches just move functions out of mmc_test.c into core.c. Those
functions will later be used by both mmc_test.c and mmc_ffu.c.  Contrary to
Avi's patch I didn't add static helper functions to mmc_test.c, e.g. 
there's no mmc_test_prepare_mrq() that calls mmc_prepare_mrq().  It's
simpler to call mmc_prepare_mrq() directly.  It's just one more dereference
from *mmc_card to *mmc_test_card anyway.

The patch [6/6] is http://www.spinics.net/lists/linux-mmc/msg29326.html, but
with less checkpatch warnings.  And it doesn't use mmc_send_ext_csd()
anymore, which has been deleted since November.

I'm sending this patch as RFC now. It compiles (for me). But I get the
firmware update file from Kingston only next Tuesday.  That means that so
far I haven't been testing it. It won't do anything without the proper
user-space command in mmc-utils anyway :-)

Comments welcome (I intent to get this patch into the kernel)

The patch is against Linux GIT (v4.3-11748-g46d862b).

Holger

 drivers/mmc/card/Kconfig|  11 +
 drivers/mmc/card/Makefile   |   1 +
 drivers/mmc/card/block.c|   5 +
 drivers/mmc/card/mmc_ffu.c  | 489 
 drivers/mmc/card/mmc_test.c | 235 +
 drivers/mmc/core/core.c | 134 
 drivers/mmc/core/mmc_ops.c  |   4 +-
 include/linux/mmc/card.h|   1 +
 include/linux/mmc/core.h|  41 
 include/linux/mmc/mmc.h |   6 +
 10 files changed, 739 insertions(+), 188 deletions(-)
 create mode 100644 drivers/mmc/card/mmc_ffu.c

-- 
2.1.4

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

[PATCH 2/6] mmc: move mmc_wait_busy() to core

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

Signed-off-by: Holger Schurig 
---
 drivers/mmc/card/mmc_test.c | 46 -
 drivers/mmc/core/core.c | 38 +
 include/linux/mmc/core.h|  1 +
 3 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 69b6c45..d1c2d22 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -184,44 +184,6 @@ static int mmc_test_set_blksize(struct mmc_test_card 
*test, unsigned size)
return mmc_set_blocklen(test->card, size);
 }
 
-static int mmc_test_busy(struct mmc_command *cmd)
-{
-   return !(cmd->resp[0] & R1_READY_FOR_DATA) ||
-   (R1_CURRENT_STATE(cmd->resp[0]) == R1_STATE_PRG);
-}
-
-/*
- * Wait for the card to finish the busy state
- */
-static int mmc_test_wait_busy(struct mmc_test_card *test)
-{
-   int ret, busy;
-   struct mmc_command cmd = {0};
-
-   busy = 0;
-   do {
-   memset(, 0, sizeof(struct mmc_command));
-
-   cmd.opcode = MMC_SEND_STATUS;
-   cmd.arg = test->card->rca << 16;
-   cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
-
-   ret = mmc_wait_for_cmd(test->card->host, , 0);
-   if (ret)
-   break;
-
-   if (!busy && mmc_test_busy()) {
-   busy = 1;
-   if (test->card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)
-   pr_info("%s: Warning: Host did not "
-   "wait for busy state to end.\n",
-   mmc_hostname(test->card->host));
-   }
-   } while (mmc_test_busy());
-
-   return ret;
-}
-
 /*
  * Transfer a single sector of kernel addressable data
  */
@@ -250,7 +212,7 @@ static int mmc_test_buffer_transfer(struct mmc_test_card 
*test,
if (data.error)
return data.error;
 
-   return mmc_test_wait_busy(test);
+   return mmc_wait_busy(test->card);
 }
 
 static void mmc_test_free_mem(struct mmc_test_mem *mem)
@@ -675,7 +637,7 @@ static int mmc_test_check_result_async(struct mmc_card 
*card,
struct mmc_test_async_req *test_async =
container_of(areq, struct mmc_test_async_req, areq);
 
-   mmc_test_wait_busy(test_async->test);
+   mmc_wait_busy(test_async->test->card);
 
return mmc_test_check_result(test_async->test, areq->mrq);
 }
@@ -812,7 +774,7 @@ static int mmc_test_simple_transfer(struct mmc_test_card 
*test,
 
mmc_wait_for_req(test->card->host, );
 
-   mmc_test_wait_busy(test);
+   mmc_wait_busy(test->card);
 
return mmc_test_check_result(test, );
 }
@@ -841,7 +803,7 @@ static int mmc_test_broken_transfer(struct mmc_test_card 
*test,
 
mmc_wait_for_req(test->card->host, );
 
-   mmc_test_wait_busy(test);
+   mmc_wait_busy(test->card);
 
return mmc_test_check_broken_result(test, );
 }
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2b5e398..df5a61c 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2856,6 +2856,44 @@ void mmc_prepare_mrq(struct mmc_card *card,
 }
 EXPORT_SYMBOL(mmc_prepare_mrq);
 
+static int mmc_test_busy(struct mmc_command *cmd)
+{
+   return !(cmd->resp[0] & R1_READY_FOR_DATA) ||
+   (R1_CURRENT_STATE(cmd->resp[0]) == R1_STATE_PRG);
+}
+
+/*
+ * Wait for the card to finish the busy state
+ */
+int mmc_wait_busy(struct mmc_card *card)
+{
+   int ret, busy;
+   struct mmc_command cmd = {0};
+
+   busy = 0;
+   do {
+   memset(, 0, sizeof(struct mmc_command));
+
+   cmd.opcode = MMC_SEND_STATUS;
+   cmd.arg = card->rca << 16;
+   cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
+
+   ret = mmc_wait_for_cmd(card->host, , 0);
+   if (ret)
+   break;
+
+   if (!busy && mmc_test_busy()) {
+   busy = 1;
+   if (card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)
+   pr_info("%s: Warning: Host did not wait for 
busy state to end.\n",
+   mmc_hostname(card->host));
+   }
+   } while (mmc_test_busy());
+
+   return ret;
+}
+EXPORT_SYMBOL(mmc_wait_busy);
+
 /**
  * mmc_init_context_info() - init synchronization context
  * @host: mmc host
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index f8db960..50e37e1 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -199,6 +199,

[PATCH 3/6] mmc: move mmc_check_result() to core.c

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

This also adds global MMC_RESULT_ variables that show if some condition
stems from the host controller or the card/chip.  This is helpful to
the source in printk.

Signed-off-by: Holger Schurig 
---
 drivers/mmc/card/mmc_test.c | 109 +++-
 drivers/mmc/core/core.c |  28 
 include/linux/mmc/core.h|   8 
 3 files changed, 74 insertions(+), 71 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index d1c2d22..1d9d997 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -24,11 +24,6 @@
 #include 
 #include 
 
-#define RESULT_OK  0
-#define RESULT_FAIL1
-#define RESULT_UNSUP_HOST  2
-#define RESULT_UNSUP_CARD  3
-
 #define BUFFER_ORDER   2
 #define BUFFER_SIZE(PAGE_SIZE << BUFFER_ORDER)
 
@@ -603,34 +598,6 @@ static void mmc_test_prepare_broken_mrq(struct 
mmc_test_card *test,
}
 }
 
-/*
- * Checks that a normal transfer didn't have any errors
- */
-static int mmc_test_check_result(struct mmc_test_card *test,
-struct mmc_request *mrq)
-{
-   int ret;
-
-   BUG_ON(!mrq || !mrq->cmd || !mrq->data);
-
-   ret = 0;
-
-   if (!ret && mrq->cmd->error)
-   ret = mrq->cmd->error;
-   if (!ret && mrq->data->error)
-   ret = mrq->data->error;
-   if (!ret && mrq->stop && mrq->stop->error)
-   ret = mrq->stop->error;
-   if (!ret && mrq->data->bytes_xfered !=
-   mrq->data->blocks * mrq->data->blksz)
-   ret = RESULT_FAIL;
-
-   if (ret == -EINVAL)
-   ret = RESULT_UNSUP_HOST;
-
-   return ret;
-}
-
 static int mmc_test_check_result_async(struct mmc_card *card,
   struct mmc_async_req *areq)
 {
@@ -639,7 +606,7 @@ static int mmc_test_check_result_async(struct mmc_card 
*card,
 
mmc_wait_busy(test_async->test->card);
 
-   return mmc_test_check_result(test_async->test, areq->mrq);
+   return mmc_check_result(areq->mrq);
 }
 
 /*
@@ -657,21 +624,21 @@ static int mmc_test_check_broken_result(struct 
mmc_test_card *test,
if (!ret && mrq->cmd->error)
ret = mrq->cmd->error;
if (!ret && mrq->data->error == 0)
-   ret = RESULT_FAIL;
+   ret = MMC_RESULT_FAIL;
if (!ret && mrq->data->error != -ETIMEDOUT)
ret = mrq->data->error;
if (!ret && mrq->stop && mrq->stop->error)
ret = mrq->stop->error;
if (mrq->data->blocks > 1) {
if (!ret && mrq->data->bytes_xfered > mrq->data->blksz)
-   ret = RESULT_FAIL;
+   ret = MMC_RESULT_FAIL;
} else {
if (!ret && mrq->data->bytes_xfered > 0)
-   ret = RESULT_FAIL;
+   ret = MMC_RESULT_FAIL;
}
 
if (ret == -EINVAL)
-   ret = RESULT_UNSUP_HOST;
+   ret = MMC_RESULT_UNSUP_HOST;
 
return ret;
 }
@@ -776,7 +743,7 @@ static int mmc_test_simple_transfer(struct mmc_test_card 
*test,
 
mmc_wait_busy(test->card);
 
-   return mmc_test_check_result(test, );
+   return mmc_check_result();
 }
 
 /*
@@ -865,12 +832,12 @@ static int mmc_test_transfer(struct mmc_test_card *test,
 
for (i = 0;i < blocks * blksz;i++) {
if (test->buffer[i] != (u8)i)
-   return RESULT_FAIL;
+   return MMC_RESULT_FAIL;
}
 
for (;i < sectors * 512;i++) {
if (test->buffer[i] != 0xDF)
-   return RESULT_FAIL;
+   return MMC_RESULT_FAIL;
}
} else {
local_irq_save(flags);
@@ -878,7 +845,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
local_irq_restore(flags);
for (i = 0;i < blocks * blksz;i++) {
if (test->scratch[i] != (u8)i)
-   return RESULT_FAIL;
+   return MMC_RESULT_FAIL;
}
}
 
@@ -949,7 +916,7 @@ static int mmc_test_multi_write(struct mmc_test_card *test)
struct scatterlist sg;
 
if (test->card->host->max_blk_count == 1)
-   return RESULT_UNSUP_HOST;
+   return MMC_RESULT_UNSUP_HO

[PATCH 5/6] mmc: move mmc_send_cxd_data() to core.c

[Holger Schurig]

This function can be used to send ext_csd data towards the chip, which is
needed in the (upcoming) firmware update patch.

Signed-off-by: Holger Schurig 
---
 drivers/mmc/core/mmc_ops.c | 4 ++--
 include/linux/mmc/core.h   | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 1f44426..d1d6abc 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -287,8 +287,7 @@ mmc_send_cxd_native(struct mmc_host *host, u32 arg, u32 
*cxd, int opcode)
  * NOTE: void *buf, caller for the buf is required to use DMA-capable
  * buffer or on-stack buffer (with some overhead in callee).
  */
-static int
-mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
+int mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
u32 opcode, void *buf, unsigned len)
 {
struct mmc_request mrq = {NULL};
@@ -336,6 +335,7 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host 
*host,
 
return 0;
 }
+EXPORT_SYMBOL(mmc_send_cxd_data);
 
 int mmc_send_csd(struct mmc_card *card, u32 *csd)
 {
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 774846f..b0e0f15 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -162,6 +162,9 @@ extern void mmc_start_bkops(struct mmc_card *card, bool 
from_exception);
 extern int mmc_switch(struct mmc_card *, u8, u8, u8, unsigned int);
 extern int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error);
 extern int mmc_get_ext_csd(struct mmc_card *card, u8 **new_ext_csd);
+extern int mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
+   u32 opcode, void *buf, unsigned len);
+
 
 #define MMC_ERASE_ARG  0x
 #define MMC_SECURE_ERASE_ARG   0x8000
-- 
2.1.4

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

[PATCH 6/6] mmc: eMMC Field Firmware Update support

[Holger Schurig]

The Field Firmware Update (FFU) feature is in the eMMC 5.0 spec, see
http://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc)

This adds a new ioctl MMC_FFU_INVOKE to transfer the new Firmware data from
user space (via udev firmware request) to the eMMC device and install the
new firmware.

This solution allows to:
- complete FFU as an atomic operation, without being interrupted by other IO
  requests (theoretically the firmware update could be done completely from
  userspace, just not atomic)
- not limited in firmware data size because it's using multiple write operations
- support of both EXT_CSD_MODE_OPERATION_CODES modes

Almost completely taken from Avi Shchislowsk/Alex Lemberg patch
"[PATCH 3/3]mmc: Support-FFU-for-eMMC-v5.0".

Signed-off-by: Holger Schurig 
---
 drivers/mmc/card/Kconfig   |  11 +
 drivers/mmc/card/Makefile  |   1 +
 drivers/mmc/card/block.c   |   5 +
 drivers/mmc/card/mmc_ffu.c | 487 +
 include/linux/mmc/card.h   |   1 +
 include/linux/mmc/core.h   |  22 ++
 include/linux/mmc/mmc.h|   6 +
 7 files changed, 533 insertions(+)
 create mode 100644 drivers/mmc/card/mmc_ffu.c

diff --git a/drivers/mmc/card/Kconfig b/drivers/mmc/card/Kconfig
index 5562308..b37937b 100644
--- a/drivers/mmc/card/Kconfig
+++ b/drivers/mmc/card/Kconfig
@@ -57,6 +57,17 @@ config SDIO_UART
  SDIO function driver for SDIO cards that implements the UART
  class, as well as the GPS class which appears like a UART.
 
+config MMC_FFU
+   bool "Field Firmware Update support"
+   depends on MMC != n
+   help
+ Some eMMC 5.0 devices allow to update their firmware "in the
+ field". This option enables support for this.
+
+ If this is compiled in, you can use the mmc utility to request
+ that the kernel loads the firmware via udev and writes it
+ to the eMMC.
+
 config MMC_TEST
tristate "MMC host test driver"
help
diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile
index c73b406..99a01e8 100644
--- a/drivers/mmc/card/Makefile
+++ b/drivers/mmc/card/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
 mmc_block-objs := block.o queue.o
+obj-$(CONFIG_MMC_FFU)  += mmc_ffu.o
 obj-$(CONFIG_MMC_TEST) += mmc_test.o
 
 obj-$(CONFIG_SDIO_UART)+= sdio_uart.o
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 23b6c8e..a49cfea 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -486,6 +486,11 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, 
struct mmc_blk_data *md,
cmd.arg = idata->ic.arg;
cmd.flags = idata->ic.flags;
 
+   if (idata->ic.opcode == MMC_FFU_INVOKE_OP) {
+   err = mmc_ffu_invoke(card, idata->buf);
+   goto cmd_done;
+   }
+
if (idata->buf_bytes) {
data.sg = 
data.sg_len = 1;
diff --git a/drivers/mmc/card/mmc_ffu.c b/drivers/mmc/card/mmc_ffu.c
new file mode 100644
index 000..8501460
--- /dev/null
+++ b/drivers/mmc/card/mmc_ffu.c
@@ -0,0 +1,487 @@
+/*
+ *  Copyright 2007-2008 Pierre Ossman
+ *
+ *  Modified by SanDisk Corp., Copyright (c) 2014 SanDisk Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program includes bug.h, card.h, host.h, mmc.h, scatterlist.h,
+ * slab.h, ffu.h & swap.h header files
+ * The original, unmodified version of this program - the mmc_test.c
+ * file - is obtained under the GPL v2.0 license that is available via
+ * http://www.gnu.org/licenses/,
+ * or http://www.opensource.org/licenses/gpl-2.0.php
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct mmc_ffu_pages - pages allocated by 'alloc_pages()'.
+ * @page: first page in the allocation
+ * @order: order of the number of pages allocated
+ */
+struct mmc_ffu_pages {
+   struct page *page;
+   unsigned int order;
+};
+
+/**
+ * struct mmc_ffu_mem - allocated memory.
+ * @arr: array of allocations
+ * @cnt: number of allocations
+ */
+struct mmc_ffu_mem {
+   struct mmc_ffu_pages *arr;
+   unsigned int cnt;
+};
+
+struct mmc_ffu_area {
+   unsigned long max_sz;
+   unsigned int max_tfr;
+   unsigned int max_segs;
+   unsigned int max_seg_sz;
+   unsigned int blocks;
+   unsigned int sg_len;
+   struct mmc_ffu_mem mem;
+   struct sg_table sgtable;
+};
+
+/*
+ * Map memory into a scatterlist.
+ */
+static unsigned int mmc_ffu_map_sg(struct mmc_ffu_mem *mem, int size,
+   struct scatterlist *sglist)
+{
+   

[PATCH 4/6] mmc: move mmc_simple_transfer() to core.c

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

Signed-off-by: Holger Schurig 
---
 drivers/mmc/card/mmc_test.c | 38 ++
 drivers/mmc/core/core.c | 27 +++
 include/linux/mmc/core.h|  3 +++
 3 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 1d9d997..94298fa 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -721,32 +721,6 @@ err:
 }
 
 /*
- * Tests a basic transfer with certain parameters
- */
-static int mmc_test_simple_transfer(struct mmc_test_card *test,
-   struct scatterlist *sg, unsigned sg_len, unsigned dev_addr,
-   unsigned blocks, unsigned blksz, int write)
-{
-   struct mmc_request mrq = {0};
-   struct mmc_command cmd = {0};
-   struct mmc_command stop = {0};
-   struct mmc_data data = {0};
-
-   mrq.cmd = 
-   mrq.data = 
-   mrq.stop = 
-
-   mmc_prepare_mrq(test->card, , sg, sg_len, dev_addr,
-   blocks, blksz, write);
-
-   mmc_wait_for_req(test->card->host, );
-
-   mmc_wait_busy(test->card);
-
-   return mmc_check_result();
-}
-
-/*
  * Tests a transfer where the card will fail completely or partly
  */
 static int mmc_test_broken_transfer(struct mmc_test_card *test,
@@ -801,7 +775,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
if (ret)
return ret;
 
-   ret = mmc_test_simple_transfer(test, sg, sg_len, dev_addr,
+   ret = mmc_simple_transfer(test->card, sg, sg_len, dev_addr,
blocks, blksz, write);
if (ret)
return ret;
@@ -875,7 +849,7 @@ static int mmc_test_basic_write(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_simple_transfer(test, , 1, 0, 1, 512, 1);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 1);
 }
 
 static int mmc_test_basic_read(struct mmc_test_card *test)
@@ -889,7 +863,7 @@ static int mmc_test_basic_read(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_simple_transfer(test, , 1, 0, 1, 512, 0);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 0);
 }
 
 static int mmc_test_verify_write(struct mmc_test_card *test)
@@ -898,7 +872,7 @@ static int mmc_test_verify_write(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_transfer(test, , 1, 0, 1, 512, 1);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 1);
 }
 
 static int mmc_test_verify_read(struct mmc_test_card *test)
@@ -907,7 +881,7 @@ static int mmc_test_verify_read(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_transfer(test, , 1, 0, 1, 512, 0);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 0);
 }
 
 static int mmc_test_multi_write(struct mmc_test_card *test)
@@ -1268,7 +1242,7 @@ static int mmc_test_area_transfer(struct mmc_test_card 
*test,
 {
struct mmc_test_area *t = >area;
 
-   return mmc_test_simple_transfer(test, t->sg, t->sg_len, dev_addr,
+   return mmc_simple_transfer(test->card, t->sg, t->sg_len, dev_addr,
t->blocks, 512, write);
 }
 
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 3254bce..fbc59ad 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2922,6 +2922,33 @@ int mmc_check_result(struct mmc_request *mrq)
 }
 EXPORT_SYMBOL(mmc_check_result);
 
+/*
+ * Run a basic transfer
+ */
+int mmc_simple_transfer(struct mmc_card *card,
+   struct scatterlist *sg, unsigned sg_len, unsigned dev_addr,
+   unsigned blocks, unsigned blksz, int write)
+{
+   struct mmc_request mrq = {0};
+   struct mmc_command cmd = {0};
+   struct mmc_command stop = {0};
+   struct mmc_data data = {0};
+
+   mrq.cmd = 
+   mrq.data = 
+   mrq.stop = 
+
+   mmc_prepare_mrq(card, , sg, sg_len, dev_addr,
+   blocks, blksz, write);
+
+   mmc_wait_for_req(card->host, );
+
+   mmc_wait_busy(card);
+
+   return mmc_check_result();
+}
+EXPORT_SYMBOL(mmc_simple_transfer);
+
 /**
  * mmc_init_context_info() - init synchronization context
  * @host: mmc host
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index a5ad2d8..774846f 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -208,6 +208,9 @@ extern void mmc_prepare_mrq(struct mmc_card *card,
unsigned dev_addr, unsigned blocks, unsigned blksz, int write);
 extern int mmc_wait_busy(struct mmc_card *card);
 extern int mmc_check_result(struct mmc_request *mrq);
+extern int mmc_simple_transfer(struct mmc_card *test,
+   struct scatte

[PATCH 4/6] mmc: move mmc_simple_transfer() to core.c

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

Signed-off-by: Holger Schurig <holgerschu...@gmail.com>
---
 drivers/mmc/card/mmc_test.c | 38 ++
 drivers/mmc/core/core.c | 27 +++
 include/linux/mmc/core.h|  3 +++
 3 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 1d9d997..94298fa 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -721,32 +721,6 @@ err:
 }
 
 /*
- * Tests a basic transfer with certain parameters
- */
-static int mmc_test_simple_transfer(struct mmc_test_card *test,
-   struct scatterlist *sg, unsigned sg_len, unsigned dev_addr,
-   unsigned blocks, unsigned blksz, int write)
-{
-   struct mmc_request mrq = {0};
-   struct mmc_command cmd = {0};
-   struct mmc_command stop = {0};
-   struct mmc_data data = {0};
-
-   mrq.cmd = 
-   mrq.data = 
-   mrq.stop = 
-
-   mmc_prepare_mrq(test->card, , sg, sg_len, dev_addr,
-   blocks, blksz, write);
-
-   mmc_wait_for_req(test->card->host, );
-
-   mmc_wait_busy(test->card);
-
-   return mmc_check_result();
-}
-
-/*
  * Tests a transfer where the card will fail completely or partly
  */
 static int mmc_test_broken_transfer(struct mmc_test_card *test,
@@ -801,7 +775,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
if (ret)
return ret;
 
-   ret = mmc_test_simple_transfer(test, sg, sg_len, dev_addr,
+   ret = mmc_simple_transfer(test->card, sg, sg_len, dev_addr,
blocks, blksz, write);
if (ret)
return ret;
@@ -875,7 +849,7 @@ static int mmc_test_basic_write(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_simple_transfer(test, , 1, 0, 1, 512, 1);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 1);
 }
 
 static int mmc_test_basic_read(struct mmc_test_card *test)
@@ -889,7 +863,7 @@ static int mmc_test_basic_read(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_simple_transfer(test, , 1, 0, 1, 512, 0);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 0);
 }
 
 static int mmc_test_verify_write(struct mmc_test_card *test)
@@ -898,7 +872,7 @@ static int mmc_test_verify_write(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_transfer(test, , 1, 0, 1, 512, 1);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 1);
 }
 
 static int mmc_test_verify_read(struct mmc_test_card *test)
@@ -907,7 +881,7 @@ static int mmc_test_verify_read(struct mmc_test_card *test)
 
sg_init_one(, test->buffer, 512);
 
-   return mmc_test_transfer(test, , 1, 0, 1, 512, 0);
+   return mmc_simple_transfer(test->card, , 1, 0, 1, 512, 0);
 }
 
 static int mmc_test_multi_write(struct mmc_test_card *test)
@@ -1268,7 +1242,7 @@ static int mmc_test_area_transfer(struct mmc_test_card 
*test,
 {
struct mmc_test_area *t = >area;
 
-   return mmc_test_simple_transfer(test, t->sg, t->sg_len, dev_addr,
+   return mmc_simple_transfer(test->card, t->sg, t->sg_len, dev_addr,
t->blocks, 512, write);
 }
 
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 3254bce..fbc59ad 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2922,6 +2922,33 @@ int mmc_check_result(struct mmc_request *mrq)
 }
 EXPORT_SYMBOL(mmc_check_result);
 
+/*
+ * Run a basic transfer
+ */
+int mmc_simple_transfer(struct mmc_card *card,
+   struct scatterlist *sg, unsigned sg_len, unsigned dev_addr,
+   unsigned blocks, unsigned blksz, int write)
+{
+   struct mmc_request mrq = {0};
+   struct mmc_command cmd = {0};
+   struct mmc_command stop = {0};
+   struct mmc_data data = {0};
+
+   mrq.cmd = 
+   mrq.data = 
+   mrq.stop = 
+
+   mmc_prepare_mrq(card, , sg, sg_len, dev_addr,
+   blocks, blksz, write);
+
+   mmc_wait_for_req(card->host, );
+
+   mmc_wait_busy(card);
+
+   return mmc_check_result();
+}
+EXPORT_SYMBOL(mmc_simple_transfer);
+
 /**
  * mmc_init_context_info() - init synchronization context
  * @host: mmc host
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index a5ad2d8..774846f 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -208,6 +208,9 @@ extern void mmc_prepare_mrq(struct mmc_card *card,
unsigned dev_addr, unsigned blocks, unsigned blksz, int write);
 extern int mmc_wait_busy(struct mmc_card *card);
 extern int mmc_check_result(struct mmc_request *mrq);
+extern int mmc_simple_transfer(struct mmc_

[PATCH 6/6] mmc: eMMC Field Firmware Update support

[Holger Schurig]

The Field Firmware Update (FFU) feature is in the eMMC 5.0 spec, see
http://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc)

This adds a new ioctl MMC_FFU_INVOKE to transfer the new Firmware data from
user space (via udev firmware request) to the eMMC device and install the
new firmware.

This solution allows to:
- complete FFU as an atomic operation, without being interrupted by other IO
  requests (theoretically the firmware update could be done completely from
  userspace, just not atomic)
- not limited in firmware data size because it's using multiple write operations
- support of both EXT_CSD_MODE_OPERATION_CODES modes

Almost completely taken from Avi Shchislowsk/Alex Lemberg patch
"[PATCH 3/3]mmc: Support-FFU-for-eMMC-v5.0".

Signed-off-by: Holger Schurig <holgerschu...@gmail.com>
---
 drivers/mmc/card/Kconfig   |  11 +
 drivers/mmc/card/Makefile  |   1 +
 drivers/mmc/card/block.c   |   5 +
 drivers/mmc/card/mmc_ffu.c | 487 +
 include/linux/mmc/card.h   |   1 +
 include/linux/mmc/core.h   |  22 ++
 include/linux/mmc/mmc.h|   6 +
 7 files changed, 533 insertions(+)
 create mode 100644 drivers/mmc/card/mmc_ffu.c

diff --git a/drivers/mmc/card/Kconfig b/drivers/mmc/card/Kconfig
index 5562308..b37937b 100644
--- a/drivers/mmc/card/Kconfig
+++ b/drivers/mmc/card/Kconfig
@@ -57,6 +57,17 @@ config SDIO_UART
  SDIO function driver for SDIO cards that implements the UART
  class, as well as the GPS class which appears like a UART.
 
+config MMC_FFU
+   bool "Field Firmware Update support"
+   depends on MMC != n
+   help
+ Some eMMC 5.0 devices allow to update their firmware "in the
+ field". This option enables support for this.
+
+ If this is compiled in, you can use the mmc utility to request
+ that the kernel loads the firmware via udev and writes it
+ to the eMMC.
+
 config MMC_TEST
tristate "MMC host test driver"
help
diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile
index c73b406..99a01e8 100644
--- a/drivers/mmc/card/Makefile
+++ b/drivers/mmc/card/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
 mmc_block-objs := block.o queue.o
+obj-$(CONFIG_MMC_FFU)  += mmc_ffu.o
 obj-$(CONFIG_MMC_TEST) += mmc_test.o
 
 obj-$(CONFIG_SDIO_UART)+= sdio_uart.o
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 23b6c8e..a49cfea 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -486,6 +486,11 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, 
struct mmc_blk_data *md,
cmd.arg = idata->ic.arg;
cmd.flags = idata->ic.flags;
 
+   if (idata->ic.opcode == MMC_FFU_INVOKE_OP) {
+   err = mmc_ffu_invoke(card, idata->buf);
+   goto cmd_done;
+   }
+
if (idata->buf_bytes) {
data.sg = 
data.sg_len = 1;
diff --git a/drivers/mmc/card/mmc_ffu.c b/drivers/mmc/card/mmc_ffu.c
new file mode 100644
index 000..8501460
--- /dev/null
+++ b/drivers/mmc/card/mmc_ffu.c
@@ -0,0 +1,487 @@
+/*
+ *  Copyright 2007-2008 Pierre Ossman
+ *
+ *  Modified by SanDisk Corp., Copyright (c) 2014 SanDisk Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ *
+ * This program includes bug.h, card.h, host.h, mmc.h, scatterlist.h,
+ * slab.h, ffu.h & swap.h header files
+ * The original, unmodified version of this program - the mmc_test.c
+ * file - is obtained under the GPL v2.0 license that is available via
+ * http://www.gnu.org/licenses/,
+ * or http://www.opensource.org/licenses/gpl-2.0.php
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct mmc_ffu_pages - pages allocated by 'alloc_pages()'.
+ * @page: first page in the allocation
+ * @order: order of the number of pages allocated
+ */
+struct mmc_ffu_pages {
+   struct page *page;
+   unsigned int order;
+};
+
+/**
+ * struct mmc_ffu_mem - allocated memory.
+ * @arr: array of allocations
+ * @cnt: number of allocations
+ */
+struct mmc_ffu_mem {
+   struct mmc_ffu_pages *arr;
+   unsigned int cnt;
+};
+
+struct mmc_ffu_area {
+   unsigned long max_sz;
+   unsigned int max_tfr;
+   unsigned int max_segs;
+   unsigned int max_seg_sz;
+   unsigned int blocks;
+   unsigned int sg_len;
+   struct mmc_ffu_mem mem;
+   struct sg_table sgtable;
+};
+
+/*
+ * Map memory into a scatterlist.
+ */
+static unsigned int mmc_ffu_map_sg(struct mmc_ffu_mem *mem, int size,
+   struc

[PATCH 1/6] mmc: move mmc_prepare_mrq() to core.c

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

Signed-off-by: Holger Schurig <holgerschu...@gmail.com>
---
 drivers/mmc/card/mmc_test.c | 48 -
 drivers/mmc/core/core.c | 41 ++
 include/linux/mmc/core.h|  4 
 3 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 7fc9174..69b6c45 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -184,46 +184,6 @@ static int mmc_test_set_blksize(struct mmc_test_card 
*test, unsigned size)
return mmc_set_blocklen(test->card, size);
 }
 
-/*
- * Fill in the mmc_request structure given a set of transfer parameters.
- */
-static void mmc_test_prepare_mrq(struct mmc_test_card *test,
-   struct mmc_request *mrq, struct scatterlist *sg, unsigned sg_len,
-   unsigned dev_addr, unsigned blocks, unsigned blksz, int write)
-{
-   BUG_ON(!mrq || !mrq->cmd || !mrq->data || !mrq->stop);
-
-   if (blocks > 1) {
-   mrq->cmd->opcode = write ?
-   MMC_WRITE_MULTIPLE_BLOCK : MMC_READ_MULTIPLE_BLOCK;
-   } else {
-   mrq->cmd->opcode = write ?
-   MMC_WRITE_BLOCK : MMC_READ_SINGLE_BLOCK;
-   }
-
-   mrq->cmd->arg = dev_addr;
-   if (!mmc_card_blockaddr(test->card))
-   mrq->cmd->arg <<= 9;
-
-   mrq->cmd->flags = MMC_RSP_R1 | MMC_CMD_ADTC;
-
-   if (blocks == 1)
-   mrq->stop = NULL;
-   else {
-   mrq->stop->opcode = MMC_STOP_TRANSMISSION;
-   mrq->stop->arg = 0;
-   mrq->stop->flags = MMC_RSP_R1B | MMC_CMD_AC;
-   }
-
-   mrq->data->blksz = blksz;
-   mrq->data->blocks = blocks;
-   mrq->data->flags = write ? MMC_DATA_WRITE : MMC_DATA_READ;
-   mrq->data->sg = sg;
-   mrq->data->sg_len = sg_len;
-
-   mmc_set_data_timeout(mrq->data, test->card);
-}
-
 static int mmc_test_busy(struct mmc_command *cmd)
 {
return !(cmd->resp[0] & R1_READY_FOR_DATA) ||
@@ -281,7 +241,7 @@ static int mmc_test_buffer_transfer(struct mmc_test_card 
*test,
 
sg_init_one(, buffer, blksz);
 
-   mmc_test_prepare_mrq(test, , , 1, addr, 1, blksz, write);
+   mmc_prepare_mrq(test->card, , , 1, addr, 1, blksz, write);
 
mmc_wait_for_req(test->card->host, );
 
@@ -805,7 +765,7 @@ static int mmc_test_nonblock_transfer(struct mmc_test_card 
*test,
other_areq->err_check = mmc_test_check_result_async;
 
for (i = 0; i < count; i++) {
-   mmc_test_prepare_mrq(test, cur_areq->mrq, sg, sg_len, dev_addr,
+   mmc_prepare_mrq(test->card, cur_areq->mrq, sg, sg_len, dev_addr,
 blocks, blksz, write);
done_areq = mmc_start_req(test->card->host, cur_areq, );
 
@@ -847,7 +807,7 @@ static int mmc_test_simple_transfer(struct mmc_test_card 
*test,
mrq.data = 
mrq.stop = 
 
-   mmc_test_prepare_mrq(test, , sg, sg_len, dev_addr,
+   mmc_prepare_mrq(test->card, , sg, sg_len, dev_addr,
blocks, blksz, write);
 
mmc_wait_for_req(test->card->host, );
@@ -876,7 +836,7 @@ static int mmc_test_broken_transfer(struct mmc_test_card 
*test,
 
sg_init_one(, test->buffer, blocks * blksz);
 
-   mmc_test_prepare_mrq(test, , , 1, 0, blocks, blksz, write);
+   mmc_prepare_mrq(test->card, , , 1, 0, blocks, blksz, write);
mmc_test_prepare_broken_mrq(test, , write);
 
mmc_wait_for_req(test->card->host, );
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5ae89e4..2b5e398 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2815,6 +2815,47 @@ int mmc_pm_notify(struct notifier_block *notify_block,
 }
 #endif
 
+/*
+ * Fill in the mmc_request structure given a set of transfer parameters.
+ */
+void mmc_prepare_mrq(struct mmc_card *card,
+   struct mmc_request *mrq, struct scatterlist *sg, unsigned sg_len,
+   unsigned dev_addr, unsigned blocks, unsigned blksz, int write)
+{
+   BUG_ON(!mrq || !mrq->cmd || !mrq->data || !mrq->stop);
+
+   if (blocks > 1) {
+   mrq->cmd->opcode = write ?
+   MMC_WRITE_MULTIPLE_BLOCK : MMC_READ_MULTIPLE_BLOCK;
+   } else {
+   mrq->cmd->opcode = write ?
+   MMC_WRITE_BLOCK : MMC_READ_SINGLE_BLOCK;
+   }
+
+   mrq->cmd->arg = dev_addr;
+   if (!mmc_card_blockaddr(card))
+   mrq->cmd->arg <<= 9;
+
+   mrq->cmd->flags = MMC_RSP_R1 | MMC_CMD_ADTC;
+
+

[RFC 0/6] mmc: Field Firmware Update

[Holger Schurig]

There have been some attempts to add FFU (field firmware update).  The last
AFAIK in Nov 2014, http://www.spinics.net/lists/linux-mmc/msg29324.html

But it seems that the committers weren't persistent enought.

I took the liberty to take Avi's patch and make it hopefully
maintainer-review friendly.

The first 5 patches just move functions out of mmc_test.c into core.c. Those
functions will later be used by both mmc_test.c and mmc_ffu.c.  Contrary to
Avi's patch I didn't add static helper functions to mmc_test.c, e.g. 
there's no mmc_test_prepare_mrq() that calls mmc_prepare_mrq().  It's
simpler to call mmc_prepare_mrq() directly.  It's just one more dereference
from *mmc_card to *mmc_test_card anyway.

The patch [6/6] is http://www.spinics.net/lists/linux-mmc/msg29326.html, but
with less checkpatch warnings.  And it doesn't use mmc_send_ext_csd()
anymore, which has been deleted since November.

I'm sending this patch as RFC now. It compiles (for me). But I get the
firmware update file from Kingston only next Tuesday.  That means that so
far I haven't been testing it. It won't do anything without the proper
user-space command in mmc-utils anyway :-)

Comments welcome (I intent to get this patch into the kernel)

The patch is against Linux GIT (v4.3-11748-g46d862b).

Holger

 drivers/mmc/card/Kconfig|  11 +
 drivers/mmc/card/Makefile   |   1 +
 drivers/mmc/card/block.c|   5 +
 drivers/mmc/card/mmc_ffu.c  | 489 
 drivers/mmc/card/mmc_test.c | 235 +
 drivers/mmc/core/core.c | 134 
 drivers/mmc/core/mmc_ops.c  |   4 +-
 include/linux/mmc/card.h|   1 +
 include/linux/mmc/core.h|  41 
 include/linux/mmc/mmc.h |   6 +
 10 files changed, 739 insertions(+), 188 deletions(-)
 create mode 100644 drivers/mmc/card/mmc_ffu.c

-- 
2.1.4

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

[PATCH 3/6] mmc: move mmc_check_result() to core.c

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

This also adds global MMC_RESULT_ variables that show if some condition
stems from the host controller or the card/chip.  This is helpful to
the source in printk.

Signed-off-by: Holger Schurig <holgerschu...@gmail.com>
---
 drivers/mmc/card/mmc_test.c | 109 +++-
 drivers/mmc/core/core.c |  28 
 include/linux/mmc/core.h|   8 
 3 files changed, 74 insertions(+), 71 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index d1c2d22..1d9d997 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -24,11 +24,6 @@
 #include 
 #include 
 
-#define RESULT_OK  0
-#define RESULT_FAIL1
-#define RESULT_UNSUP_HOST  2
-#define RESULT_UNSUP_CARD  3
-
 #define BUFFER_ORDER   2
 #define BUFFER_SIZE(PAGE_SIZE << BUFFER_ORDER)
 
@@ -603,34 +598,6 @@ static void mmc_test_prepare_broken_mrq(struct 
mmc_test_card *test,
}
 }
 
-/*
- * Checks that a normal transfer didn't have any errors
- */
-static int mmc_test_check_result(struct mmc_test_card *test,
-struct mmc_request *mrq)
-{
-   int ret;
-
-   BUG_ON(!mrq || !mrq->cmd || !mrq->data);
-
-   ret = 0;
-
-   if (!ret && mrq->cmd->error)
-   ret = mrq->cmd->error;
-   if (!ret && mrq->data->error)
-   ret = mrq->data->error;
-   if (!ret && mrq->stop && mrq->stop->error)
-   ret = mrq->stop->error;
-   if (!ret && mrq->data->bytes_xfered !=
-   mrq->data->blocks * mrq->data->blksz)
-   ret = RESULT_FAIL;
-
-   if (ret == -EINVAL)
-   ret = RESULT_UNSUP_HOST;
-
-   return ret;
-}
-
 static int mmc_test_check_result_async(struct mmc_card *card,
   struct mmc_async_req *areq)
 {
@@ -639,7 +606,7 @@ static int mmc_test_check_result_async(struct mmc_card 
*card,
 
mmc_wait_busy(test_async->test->card);
 
-   return mmc_test_check_result(test_async->test, areq->mrq);
+   return mmc_check_result(areq->mrq);
 }
 
 /*
@@ -657,21 +624,21 @@ static int mmc_test_check_broken_result(struct 
mmc_test_card *test,
if (!ret && mrq->cmd->error)
ret = mrq->cmd->error;
if (!ret && mrq->data->error == 0)
-   ret = RESULT_FAIL;
+   ret = MMC_RESULT_FAIL;
if (!ret && mrq->data->error != -ETIMEDOUT)
ret = mrq->data->error;
if (!ret && mrq->stop && mrq->stop->error)
ret = mrq->stop->error;
if (mrq->data->blocks > 1) {
if (!ret && mrq->data->bytes_xfered > mrq->data->blksz)
-   ret = RESULT_FAIL;
+   ret = MMC_RESULT_FAIL;
} else {
if (!ret && mrq->data->bytes_xfered > 0)
-   ret = RESULT_FAIL;
+   ret = MMC_RESULT_FAIL;
}
 
if (ret == -EINVAL)
-   ret = RESULT_UNSUP_HOST;
+   ret = MMC_RESULT_UNSUP_HOST;
 
return ret;
 }
@@ -776,7 +743,7 @@ static int mmc_test_simple_transfer(struct mmc_test_card 
*test,
 
mmc_wait_busy(test->card);
 
-   return mmc_test_check_result(test, );
+   return mmc_check_result();
 }
 
 /*
@@ -865,12 +832,12 @@ static int mmc_test_transfer(struct mmc_test_card *test,
 
for (i = 0;i < blocks * blksz;i++) {
if (test->buffer[i] != (u8)i)
-   return RESULT_FAIL;
+   return MMC_RESULT_FAIL;
}
 
for (;i < sectors * 512;i++) {
if (test->buffer[i] != 0xDF)
-   return RESULT_FAIL;
+   return MMC_RESULT_FAIL;
}
} else {
local_irq_save(flags);
@@ -878,7 +845,7 @@ static int mmc_test_transfer(struct mmc_test_card *test,
local_irq_restore(flags);
for (i = 0;i < blocks * blksz;i++) {
if (test->scratch[i] != (u8)i)
-   return RESULT_FAIL;
+   return MMC_RESULT_FAIL;
}
}
 
@@ -949,7 +916,7 @@ static int mmc_test_multi_write(struct mmc_test_card *test)
struct scatterlist sg;
 
if (test->card->host->max_blk_count == 1)
-   return RESULT_UNSUP_HOST;
+   

[PATCH 2/6] mmc: move mmc_wait_busy() to core

[Holger Schurig]

Currently this function is used inside the mmc test driver. But it is also
usable in the (upcoming) firmware update patch. So move this function out
of mmc_test.c into core.c.

Signed-off-by: Holger Schurig <holgerschu...@gmail.com>
---
 drivers/mmc/card/mmc_test.c | 46 -
 drivers/mmc/core/core.c | 38 +
 include/linux/mmc/core.h|  1 +
 3 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/drivers/mmc/card/mmc_test.c b/drivers/mmc/card/mmc_test.c
index 69b6c45..d1c2d22 100644
--- a/drivers/mmc/card/mmc_test.c
+++ b/drivers/mmc/card/mmc_test.c
@@ -184,44 +184,6 @@ static int mmc_test_set_blksize(struct mmc_test_card 
*test, unsigned size)
return mmc_set_blocklen(test->card, size);
 }
 
-static int mmc_test_busy(struct mmc_command *cmd)
-{
-   return !(cmd->resp[0] & R1_READY_FOR_DATA) ||
-   (R1_CURRENT_STATE(cmd->resp[0]) == R1_STATE_PRG);
-}
-
-/*
- * Wait for the card to finish the busy state
- */
-static int mmc_test_wait_busy(struct mmc_test_card *test)
-{
-   int ret, busy;
-   struct mmc_command cmd = {0};
-
-   busy = 0;
-   do {
-   memset(, 0, sizeof(struct mmc_command));
-
-   cmd.opcode = MMC_SEND_STATUS;
-   cmd.arg = test->card->rca << 16;
-   cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
-
-   ret = mmc_wait_for_cmd(test->card->host, , 0);
-   if (ret)
-   break;
-
-   if (!busy && mmc_test_busy()) {
-   busy = 1;
-   if (test->card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)
-   pr_info("%s: Warning: Host did not "
-   "wait for busy state to end.\n",
-   mmc_hostname(test->card->host));
-   }
-   } while (mmc_test_busy());
-
-   return ret;
-}
-
 /*
  * Transfer a single sector of kernel addressable data
  */
@@ -250,7 +212,7 @@ static int mmc_test_buffer_transfer(struct mmc_test_card 
*test,
if (data.error)
return data.error;
 
-   return mmc_test_wait_busy(test);
+   return mmc_wait_busy(test->card);
 }
 
 static void mmc_test_free_mem(struct mmc_test_mem *mem)
@@ -675,7 +637,7 @@ static int mmc_test_check_result_async(struct mmc_card 
*card,
struct mmc_test_async_req *test_async =
container_of(areq, struct mmc_test_async_req, areq);
 
-   mmc_test_wait_busy(test_async->test);
+   mmc_wait_busy(test_async->test->card);
 
return mmc_test_check_result(test_async->test, areq->mrq);
 }
@@ -812,7 +774,7 @@ static int mmc_test_simple_transfer(struct mmc_test_card 
*test,
 
mmc_wait_for_req(test->card->host, );
 
-   mmc_test_wait_busy(test);
+   mmc_wait_busy(test->card);
 
return mmc_test_check_result(test, );
 }
@@ -841,7 +803,7 @@ static int mmc_test_broken_transfer(struct mmc_test_card 
*test,
 
mmc_wait_for_req(test->card->host, );
 
-   mmc_test_wait_busy(test);
+   mmc_wait_busy(test->card);
 
return mmc_test_check_broken_result(test, );
 }
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2b5e398..df5a61c 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2856,6 +2856,44 @@ void mmc_prepare_mrq(struct mmc_card *card,
 }
 EXPORT_SYMBOL(mmc_prepare_mrq);
 
+static int mmc_test_busy(struct mmc_command *cmd)
+{
+   return !(cmd->resp[0] & R1_READY_FOR_DATA) ||
+   (R1_CURRENT_STATE(cmd->resp[0]) == R1_STATE_PRG);
+}
+
+/*
+ * Wait for the card to finish the busy state
+ */
+int mmc_wait_busy(struct mmc_card *card)
+{
+   int ret, busy;
+   struct mmc_command cmd = {0};
+
+   busy = 0;
+   do {
+   memset(, 0, sizeof(struct mmc_command));
+
+   cmd.opcode = MMC_SEND_STATUS;
+   cmd.arg = card->rca << 16;
+   cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
+
+   ret = mmc_wait_for_cmd(card->host, , 0);
+   if (ret)
+   break;
+
+   if (!busy && mmc_test_busy()) {
+   busy = 1;
+   if (card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)
+   pr_info("%s: Warning: Host did not wait for 
busy state to end.\n",
+   mmc_hostname(card->host));
+   }
+   } while (mmc_test_busy());
+
+   return ret;
+}
+EXPORT_SYMBOL(mmc_wait_busy);
+
 /**
  * mmc_init_context_info() - init synchronization context
  * @host: mmc host
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index f8db960..50e37e1 100644
--- a/include/linux/mmc/core.h
+++ b/include/l

[PATCH 5/6] mmc: move mmc_send_cxd_data() to core.c

[Holger Schurig]

This function can be used to send ext_csd data towards the chip, which is
needed in the (upcoming) firmware update patch.

Signed-off-by: Holger Schurig <holgerschu...@gmail.com>
---
 drivers/mmc/core/mmc_ops.c | 4 ++--
 include/linux/mmc/core.h   | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 1f44426..d1d6abc 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -287,8 +287,7 @@ mmc_send_cxd_native(struct mmc_host *host, u32 arg, u32 
*cxd, int opcode)
  * NOTE: void *buf, caller for the buf is required to use DMA-capable
  * buffer or on-stack buffer (with some overhead in callee).
  */
-static int
-mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
+int mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
u32 opcode, void *buf, unsigned len)
 {
struct mmc_request mrq = {NULL};
@@ -336,6 +335,7 @@ mmc_send_cxd_data(struct mmc_card *card, struct mmc_host 
*host,
 
return 0;
 }
+EXPORT_SYMBOL(mmc_send_cxd_data);
 
 int mmc_send_csd(struct mmc_card *card, u32 *csd)
 {
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 774846f..b0e0f15 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -162,6 +162,9 @@ extern void mmc_start_bkops(struct mmc_card *card, bool 
from_exception);
 extern int mmc_switch(struct mmc_card *, u8, u8, u8, unsigned int);
 extern int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error);
 extern int mmc_get_ext_csd(struct mmc_card *card, u8 **new_ext_csd);
+extern int mmc_send_cxd_data(struct mmc_card *card, struct mmc_host *host,
+   u32 opcode, void *buf, unsigned len);
+
 
 #define MMC_ERASE_ARG  0x
 #define MMC_SECURE_ERASE_ARG   0x8000
-- 
2.1.4

--
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 v3 0/6] mmc: imx: a few fixes and new feature

[Holger Schurig]

Can you also fix the driver to NOT use mdelay(1) while in spinlock irqsafe?

A driver with such a design should have gotten a NAK in the first place ...
--
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 v3 0/6] mmc: imx: a few fixes and new feature

[Holger Schurig]

Can you also fix the driver to NOT use mdelay(1) while in spinlock irqsafe?

A driver with such a design should have gotten a NAK in the first place ...
--
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 0/1] Add support for esdhc0 on Vybrid.

[Holger Schurig]

> Cory Tusar (1):
>   ARM: dts: vfxxx: Include support for esdhc0 functionality.
>
>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> --
> 2.3.6

Your patch looks empty.
--
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 0/1] Add support for esdhc0 on Vybrid.

[Holger Schurig]

 Cory Tusar (1):
   ARM: dts: vfxxx: Include support for esdhc0 functionality.

  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
  1 file changed, 11 insertions(+)

 --
 2.3.6

Your patch looks empty.
--
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: SDHCI: mdelay() in hot path in esdhc_pltfm_set_clock looses CAN (!) frames

[Holger Schurig]

Wow, at last some reaction. And I thought nobody cares ...

BTW, removing CONFIG_MMC_CLKGATE helped a bit, because the pointless
clock-off-clock-on while the device is booting (or accessing multiple
sectors within a short time) isn't going to happen anymore.

But really, a mdelay(1) in a driver ...
--
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: SDHCI: mdelay() in hot path in esdhc_pltfm_set_clock looses CAN (!) frames

[Holger Schurig]

Wow, at last some reaction. And I thought nobody cares ...

BTW, removing CONFIG_MMC_CLKGATE helped a bit, because the pointless
clock-off-clock-on while the device is booting (or accessing multiple
sectors within a short time) isn't going to happen anymore.

But really, a mdelay(1) in a driver ...
--
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-rc1 v21 3/6] irqchip: gic: Introduce plumbing for IPI FIQ

[Holger Schurig]

> Currently it is not possible to exploit FIQ for systems with a GIC, even
> on systems are otherwise capable of it. This patch makes it possible
> for IPIs to be delivered using FIQ.

I wonder if gic_set_group_irq() can easily be married with mxc_set_irq_fiq().

The driver sound/soc/fsl/imx-pcm-fiq.c uses mxc_set_irq_fiq() to
connect an (assembly) FIQ handler with a hardware IRQ. However, the
underlying implementation of mxc_set_irq_fiq() is only supported for
TZIC and AVIC (see arch/arm/mach-imx/irq-common.c).

On my i.MX6, which doesn't have an AVIC/TZIC but a GIC I could use a
method to turn a normal IRQ into a FIQ :-)
--
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-rc1 v21 3/6] irqchip: gic: Introduce plumbing for IPI FIQ

[Holger Schurig]

 Currently it is not possible to exploit FIQ for systems with a GIC, even
 on systems are otherwise capable of it. This patch makes it possible
 for IPIs to be delivered using FIQ.

I wonder if gic_set_group_irq() can easily be married with mxc_set_irq_fiq().

The driver sound/soc/fsl/imx-pcm-fiq.c uses mxc_set_irq_fiq() to
connect an (assembly) FIQ handler with a hardware IRQ. However, the
underlying implementation of mxc_set_irq_fiq() is only supported for
TZIC and AVIC (see arch/arm/mach-imx/irq-common.c).

On my i.MX6, which doesn't have an AVIC/TZIC but a GIC I could use a
method to turn a normal IRQ into a FIQ :-)
--
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/

SDHCI: mdelay() in hot path in esdhc_pltfm_set_clock looses CAN (!) frames

[Holger Schurig]

Hi,

I noticed in a kernel 4.0.7 that I loose CAN packets when an incoming
rsync transfer changes my eMMC or SD-Card image. I used CONFIG_FRACE
to find why this is the case, and came to this trace:

# tracer: preemptoff
#
# preemptoff latency trace v1.1.5 on 4.0.7
# 
# latency: 1046 us, #756/756, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
#-
#| task: mmcqd/0-76 (uid:0 nice:0 policy:0 rt_prio:0)
#-
#  => started at: sdhci_do_set_ios
#  => ended at:   sdhci_do_set_ios
#
#
#  _--=> CPU#
# / _-=> irqs-off
#| / _=> need-resched
#|| / _---=> hardirq/softirq
#||| / _--=> preempt-depth
# / delay
#  cmd pid   | time  |   caller
# \   /  |  \|   /
mmcqd/0-76  2d..11us : _raw_spin_lock_irq <-sdhci_do_set_ios
mmcqd/0-76  2d..22us : esdhc_writeb_le <-sdhci_do_set_ios
mmcqd/0-76  2d..24us : esdhc_pltfm_set_bus_width <-sdhci_do_set_ios
mmcqd/0-76  2d..25us : l2c210_sync <-esdhc_pltfm_set_bus_width
mmcqd/0-76  2d..27us : esdhc_writeb_le <-sdhci_do_set_ios
mmcqd/0-76  2d..29us : l2c210_sync <-esdhc_writeb_le
mmcqd/0-76  2d..2   10us : esdhc_readw_le <-sdhci_do_set_ios
mmcqd/0-76  2d..2   12us : esdhc_writew_le <-sdhci_do_set_ios
mmcqd/0-76  2d..2   14us : l2c210_sync <-esdhc_writew_le
mmcqd/0-76  2d..2   16us : l2c210_sync <-esdhc_writew_le
mmcqd/0-76  2d..2   18us : esdhc_readw_le <-sdhci_do_set_ios
mmcqd/0-76  2d..2   19us : esdhc_writew_le <-sdhci_do_set_ios
mmcqd/0-76  2d..2   21us : l2c210_sync <-esdhc_writew_le
mmcqd/0-76  2d..2   22us : esdhc_set_uhs_signaling <-sdhci_do_set_ios
mmcqd/0-76  2d..2   24us : pinctrl_select_state <-esdhc_set_uhs_signaling
mmcqd/0-76  2d..2   26us : esdhc_readl_le <-esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   28us : esdhc_writel_le <-esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   29us : l2c210_sync <-esdhc_writel_le
mmcqd/0-76  2d..2   31us : esdhc_readl_le <-esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   33us : esdhc_writel_le <-esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   34us : l2c210_sync <-esdhc_writel_le
mmcqd/0-76  2d..2   36us : l2c210_sync <-esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   37us : __timer_const_udelay <-esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   39us : __timer_delay <-__timer_const_udelay
mmcqd/0-76  2d..2   40us : read_current_timer <-__timer_delay
mmcqd/0-76  2d..2   41us : imx_read_current_timer <-read_current_timer
mmcqd/0-76  2d..2   43us : read_current_timer <-__timer_delay
mmcqd/0-76  2d..2   44us : imx_read_current_timer <-read_current_timer
mmcqd/0-76  2d..2   45us : read_current_timer <-__timer_delay


So it seems that esdhc_pltfm_set_clock() somehow waits. And really
there is an mdelay(1) there. So it waits a whopping millisecond there!

What's worse: I put a printk() into this function, just before the
mdelay(). And it get's called hundreds of times when I boot, or when I
update via rsync. And I believe that for each call the mdelay() kills
preemption.

This is bad because in the FlexCAN driver the ISR calls
napi_schedule(), which in turn clears the CAN RxFIFO. And if this
scheduling is taking too long, CAN packets are dropped. With 50 bits
per CAN packet anf 50 bit/s this can happen quite easily (the
RxFIFO is a hardware component that can hold only 6 CAN frames before
data is lost).

The mdelay() is also bad because it makes eMMC/SD-Card access WAY
slower than they could be.

I'm not firm with SDHCI, I only see that esdhc_pltfm_set_clock() is
all the time called with 0 Hz and then with 2000 Hz. Any tips on
how to get rid of this clock-off-clock-on dance?

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

SDHCI: mdelay() in hot path in esdhc_pltfm_set_clock looses CAN (!) frames

[Holger Schurig]

Hi,

I noticed in a kernel 4.0.7 that I loose CAN packets when an incoming
rsync transfer changes my eMMC or SD-Card image. I used CONFIG_FRACE
to find why this is the case, and came to this trace:

# tracer: preemptoff
#
# preemptoff latency trace v1.1.5 on 4.0.7
# 
# latency: 1046 us, #756/756, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:4)
#-
#| task: mmcqd/0-76 (uid:0 nice:0 policy:0 rt_prio:0)
#-
#  = started at: sdhci_do_set_ios
#  = ended at:   sdhci_do_set_ios
#
#
#  _--= CPU#
# / _-= irqs-off
#| / _= need-resched
#|| / _---= hardirq/softirq
#||| / _--= preempt-depth
# / delay
#  cmd pid   | time  |   caller
# \   /  |  \|   /
mmcqd/0-76  2d..11us : _raw_spin_lock_irq -sdhci_do_set_ios
mmcqd/0-76  2d..22us : esdhc_writeb_le -sdhci_do_set_ios
mmcqd/0-76  2d..24us : esdhc_pltfm_set_bus_width -sdhci_do_set_ios
mmcqd/0-76  2d..25us : l2c210_sync -esdhc_pltfm_set_bus_width
mmcqd/0-76  2d..27us : esdhc_writeb_le -sdhci_do_set_ios
mmcqd/0-76  2d..29us : l2c210_sync -esdhc_writeb_le
mmcqd/0-76  2d..2   10us : esdhc_readw_le -sdhci_do_set_ios
mmcqd/0-76  2d..2   12us : esdhc_writew_le -sdhci_do_set_ios
mmcqd/0-76  2d..2   14us : l2c210_sync -esdhc_writew_le
mmcqd/0-76  2d..2   16us : l2c210_sync -esdhc_writew_le
mmcqd/0-76  2d..2   18us : esdhc_readw_le -sdhci_do_set_ios
mmcqd/0-76  2d..2   19us : esdhc_writew_le -sdhci_do_set_ios
mmcqd/0-76  2d..2   21us : l2c210_sync -esdhc_writew_le
mmcqd/0-76  2d..2   22us : esdhc_set_uhs_signaling -sdhci_do_set_ios
mmcqd/0-76  2d..2   24us : pinctrl_select_state -esdhc_set_uhs_signaling
mmcqd/0-76  2d..2   26us : esdhc_readl_le -esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   28us : esdhc_writel_le -esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   29us : l2c210_sync -esdhc_writel_le
mmcqd/0-76  2d..2   31us : esdhc_readl_le -esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   33us : esdhc_writel_le -esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   34us : l2c210_sync -esdhc_writel_le
mmcqd/0-76  2d..2   36us : l2c210_sync -esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   37us : __timer_const_udelay -esdhc_pltfm_set_clock
mmcqd/0-76  2d..2   39us : __timer_delay -__timer_const_udelay
mmcqd/0-76  2d..2   40us : read_current_timer -__timer_delay
mmcqd/0-76  2d..2   41us : imx_read_current_timer -read_current_timer
mmcqd/0-76  2d..2   43us : read_current_timer -__timer_delay
mmcqd/0-76  2d..2   44us : imx_read_current_timer -read_current_timer
mmcqd/0-76  2d..2   45us : read_current_timer -__timer_delay


So it seems that esdhc_pltfm_set_clock() somehow waits. And really
there is an mdelay(1) there. So it waits a whopping millisecond there!

What's worse: I put a printk() into this function, just before the
mdelay(). And it get's called hundreds of times when I boot, or when I
update via rsync. And I believe that for each call the mdelay() kills
preemption.

This is bad because in the FlexCAN driver the ISR calls
napi_schedule(), which in turn clears the CAN RxFIFO. And if this
scheduling is taking too long, CAN packets are dropped. With 50 bits
per CAN packet anf 50 bit/s this can happen quite easily (the
RxFIFO is a hardware component that can hold only 6 CAN frames before
data is lost).

The mdelay() is also bad because it makes eMMC/SD-Card access WAY
slower than they could be.

I'm not firm with SDHCI, I only see that esdhc_pltfm_set_clock() is
all the time called with 0 Hz and then with 2000 Hz. Any tips on
how to get rid of this clock-off-clock-on dance?

Holger
--
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: [ath5k-devel] [PATCH 09/28] Remove ATHEROS_AR231X

[Holger Schurig]

> Having this conversation every rc1 is getting a bit silly.

Hmm, wouldn't the obvious thing than to add the driver in it's current
form into staging?  Is it well-separated from the rest of  Atheros
WLAN drivers ?
--
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: [ath5k-devel] [PATCH 09/28] Remove ATHEROS_AR231X

[Holger Schurig]

 Having this conversation every rc1 is getting a bit silly.

Hmm, wouldn't the obvious thing than to add the driver in it's current
form into staging?  Is it well-separated from the rest of  Atheros
WLAN drivers ?
--
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/

[BUG] gma500: sleeping function called from invalid context at kernel/mutex.c:413

[Holger Schurig]

Kernel: 3.10.19

>From time to time, when I booted, I had a completely dark screen (with
kernel command line quiet) and a non-blinking cursor. I wondered if
that was perhaps gma500. So I turned on various debug checks. Then
I've got the BUG from the subject.

The device is a " VGA compatible controller [0300]: Intel Corporation
System Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108]
(rev 07)".

Here's relevant "dmesg" output:

...
PCI: Using MMCONFIG for extended config space
PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
ACPI: Power Resource [FAN1] (on)
...
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
...
r8169 :02:00.0 eth0: link up
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
acpi device:04: registered as cooling_device1
acpi device:05: registered as cooling_device2
ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input7
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
fbcon: psbdrmfb (fb0) is primary device
Console: switching to colour frame buffer device 100x37
gma500 :00:02.0: fb0: psbdrmfb frame buffer device
gma500 :00:02.0: registered panic notifier
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
[drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on minor 0
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
BUG: sleeping function called from invalid context at kernel/mutex.c:413
in_atomic(): 1, irqs_disabled(): 1, pid: 310, name: Xorg
5 locks held by Xorg/310:
 #0:  (_info->lock){+.+.+.}, at: [] lock_fb_info+0x13/0x30
 #1:  (console_lock){+.+.+.}, at: [] do_fb_ioctl+0x3cf/0x44a
 #2:  ((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x1e/0x4f
 #3:  (_bd->ops_lock){+.+...}, at: []
fb_notifier_callback+0x31/0xaa
 #4:  (_bd->update_lock){+.+...}, at: []
fb_notifier_callback+0x7c/0xaa
irq event stamp: 31266
hardirqs last  enabled at (31265): []
_raw_spin_unlock_irqrestore+0x33/0x56
hardirqs last disabled at (31266): [] common_interrupt+0x2a/0x36
softirqs last  enabled at (30912): [] __do_softirq+0x1b1/0x208
softirqs last disabled at (30903): [] do_softirq+0x54/0xa1
CPU: 0 PID: 310 Comm: Xorg Tainted: G   O 3.10.19 #1
 f615dfa0 f615dfa0 f6c09ebc c12f8f85 f6c09ee0 c104dad6 c13f7580 0001
 0001 0136 f615e294 f5cc9818 f5cc9818 f6c09f30 c12faddc 0001
 ca825490 f5018104 f6330004 f615e4ac f615dfa0 f615e4b4 f6c09f98 3046
Call Trace:
 [] dump_stack+0x16/0x18
 [] __might_sleep+0xf8/0xff
 [] mutex_lock_nested+0x1e/0x317
 [] do_gma_backlight_set+0x1d/0x3d [gma500_gfx]
 [] gma_backlight_set+0x2a/0x2d [gma500_gfx]
 [] psb_intel_opregion_asle_intr+0xc4/0xe0 [gma500_gfx]
 [] psb_irq_handler+0x7e/0x176 [gma500_gfx]
 [] handle_irq_event_percpu+0x5a/0x1cf
 [] ? handle_fasteoi_irq+0x11/0x97
 [] handle_irq_event+0x2c/0x43
 [] ? handle_level_irq+0x98/0x98
 [] handle_fasteoi_irq+0x6a/0x97
   [] ? do_IRQ+0x37/0x9a
 [] ? acpi_ex_store+0xb8/0x219
 [] ? common_interrupt+0x31/0x36
 [] ? acpi_ds_load2_end_op+0x1e1/0x311
 [] ? acpi_ds_result_push+0x29/0x13e
 [] ? acpi_ds_clear_operands+0x17/0x33
 [] ? acpi_ds_exec_end_op+0x27e/0x3b0
 [] ? acpi_ps_append_arg+0x19/0x7d
 [] ? acpi_ps_parse_loop+0x4a4/0x4f0
 [] ? kfree+0xbb/0x13b
 [] ? acpi_ps_parse_aml+0x82/0x23f
 [] ? acpi_ps_execute_method+0x19c/0x23a
 [] ? acpi_ns_evaluate+0xaf/0x194
 [] ? acpi_evaluate_object+0xf1/0x1e5
 [] ? acpi_video_device_lcd_set_level+0x52/0xd3
 [] ? acpi_video_set_brightness+0x21/0x24
 [] ? fb_notifier_callback+0x8f/0xaa
 [] ? notifier_call_chain+0x25/0x46
 [] ? __blocking_notifier_call_chain+0x39/0x4f
 [] ? blocking_notifier_call_chain+0x1a/0x1c
 [] ? fb_notifier_call_chain+0x11/0x13
 [] ? fb_blank+0x6a/0x73
 [] ? do_fb_ioctl+0x3e3/0x44a
 [] ? mark_held_locks+0xb3/0xd6
 [] ? ftrace_raw_event_mm_page+0x85/0x90
 [] ? do_fb_ioctl+0x44a/0x44a
 [] ? fb_ioctl+0x20/0x29
 [] ? vfs_ioctl+0x1b/0x25
 [] ? do_vfs_ioctl+0x413/0x451
 [] ? do_mmap_pgoff+0x24c/0x2bf
 [] ? up_write+0x16/0x2b
 [] ? vm_mmap_pgoff+0x57/0x73
 [] ? restore_all+0xf/0xf
 [] ? SyS_ioctl+0x3d/0x5b
 [] ? syscall_call+0x7/0xb
=
[ INFO: inconsistent lock state ]
3.10.19 #1 Tainted: G   O
-
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
Xorg/310 [HC1[1]:SC0[0]:HE0:SE1] takes:
 (_bd->update_lock){?.+...}, at: []
do_gma_backlight_set+0x1d/0x3d [gma500_gfx]
{HARDIRQ-ON-W} state was registered at:
  [] __lock_acquire+0x564/0x1664
  [] lock_acquire+0xbf/0xfa
  [] mutex_lock_nested+0x5b/0x317
  [] psb_backlight_init+0xf4/0x149 [gma500_gfx]
  [] gma_backlight_init+0x16/0x18 [gma500_gfx]
  [] psb_driver_load+0x37e/0x3c2 [gma500_gfx]
  [] 

[BUG] gma500: sleeping function called from invalid context at kernel/mutex.c:413

[Holger Schurig]

Kernel: 3.10.19

From time to time, when I booted, I had a completely dark screen (with
kernel command line quiet) and a non-blinking cursor. I wondered if
that was perhaps gma500. So I turned on various debug checks. Then
I've got the BUG from the subject.

The device is a  VGA compatible controller [0300]: Intel Corporation
System Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108]
(rev 07).

Here's relevant dmesg output:

...
PCI: Using MMCONFIG for extended config space
PCI: Using host bridge windows from ACPI; if necessary, use
pci=nocrs and report a bug
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
ACPI: Power Resource [FAN1] (on)
...
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
...
r8169 :02:00.0 eth0: link up
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
acpi device:04: registered as cooling_device1
acpi device:05: registered as cooling_device2
ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input7
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
fbcon: psbdrmfb (fb0) is primary device
Console: switching to colour frame buffer device 100x37
gma500 :00:02.0: fb0: psbdrmfb frame buffer device
gma500 :00:02.0: registered panic notifier
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
[drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on minor 0
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
BUG: sleeping function called from invalid context at kernel/mutex.c:413
in_atomic(): 1, irqs_disabled(): 1, pid: 310, name: Xorg
5 locks held by Xorg/310:
 #0:  (fb_info-lock){+.+.+.}, at: [c1195f17] lock_fb_info+0x13/0x30
 #1:  (console_lock){+.+.+.}, at: [c1196c7a] do_fb_ioctl+0x3cf/0x44a
 #2:  ((fb_notifier_list).rwsem){.+}, at: [c1049918]
__blocking_notifier_call_chain+0x1e/0x4f
 #3:  (new_bd-ops_lock){+.+...}, at: [c11a2937]
fb_notifier_callback+0x31/0xaa
 #4:  (new_bd-update_lock){+.+...}, at: [c11a2982]
fb_notifier_callback+0x7c/0xaa
irq event stamp: 31266
hardirqs last  enabled at (31265): [c12fd1ff]
_raw_spin_unlock_irqrestore+0x33/0x56
hardirqs last disabled at (31266): [c12fe2aa] common_interrupt+0x2a/0x36
softirqs last  enabled at (30912): [c102ee2f] __do_softirq+0x1b1/0x208
softirqs last disabled at (30903): [c1002dec] do_softirq+0x54/0xa1
CPU: 0 PID: 310 Comm: Xorg Tainted: G   O 3.10.19 #1
 f615dfa0 f615dfa0 f6c09ebc c12f8f85 f6c09ee0 c104dad6 c13f7580 0001
 0001 0136 f615e294 f5cc9818 f5cc9818 f6c09f30 c12faddc 0001
 ca825490 f5018104 f6330004 f615e4ac f615dfa0 f615e4b4 f6c09f98 3046
Call Trace:
 [c12f8f85] dump_stack+0x16/0x18
 [c104dad6] __might_sleep+0xf8/0xff
 [c12faddc] mutex_lock_nested+0x1e/0x317
 [f86ee455] do_gma_backlight_set+0x1d/0x3d [gma500_gfx]
 [f86ee4ef] gma_backlight_set+0x2a/0x2d [gma500_gfx]
 [f86fa9b1] psb_intel_opregion_asle_intr+0xc4/0xe0 [gma500_gfx]
 [f86f9359] psb_irq_handler+0x7e/0x176 [gma500_gfx]
 [c107b1dc] handle_irq_event_percpu+0x5a/0x1cf
 [c107d4a9] ? handle_fasteoi_irq+0x11/0x97
 [c107b37d] handle_irq_event+0x2c/0x43
 [c107d498] ? handle_level_irq+0x98/0x98
 [c107d502] handle_fasteoi_irq+0x6a/0x97
 IRQ  [c1002c80] ? do_IRQ+0x37/0x9a
 [c11b8eab] ? acpi_ex_store+0xb8/0x219
 [c12fe2b1] ? common_interrupt+0x31/0x36
 [c11b00d8] ? acpi_ds_load2_end_op+0x1e1/0x311
 [c11b042e] ? acpi_ds_result_push+0x29/0x13e
 [c11aee7d] ? acpi_ds_clear_operands+0x17/0x33
 [c11af6e6] ? acpi_ds_exec_end_op+0x27e/0x3b0
 [c11c00b8] ? acpi_ps_append_arg+0x19/0x7d
 [c11bf3cc] ? acpi_ps_parse_loop+0x4a4/0x4f0
 [c10c6f02] ? kfree+0xbb/0x13b
 [c11bfd5f] ? acpi_ps_parse_aml+0x82/0x23f
 [c11c0482] ? acpi_ps_execute_method+0x19c/0x23a
 [c11bb6f3] ? acpi_ns_evaluate+0xaf/0x194
 [c11bdf18] ? acpi_evaluate_object+0xf1/0x1e5
 [c11c7d7e] ? acpi_video_device_lcd_set_level+0x52/0xd3
 [c11c7e57] ? acpi_video_set_brightness+0x21/0x24
 [c11a2995] ? fb_notifier_callback+0x8f/0xaa
 [c10497dc] ? notifier_call_chain+0x25/0x46
 [c1049933] ? __blocking_notifier_call_chain+0x39/0x4f
 [c1049963] ? blocking_notifier_call_chain+0x1a/0x1c
 [c1195bb5] ? fb_notifier_call_chain+0x11/0x13
 [c11960d6] ? fb_blank+0x6a/0x73
 [c1196c8e] ? do_fb_ioctl+0x3e3/0x44a
 [c106c5c7] ? mark_held_locks+0xb3/0xd6
 [c10b007b] ? ftrace_raw_event_mm_page+0x85/0x90
 [c1196cf5] ? do_fb_ioctl+0x44a/0x44a
 [c1196d15] ? fb_ioctl+0x20/0x29
 [c10da7eb] ? vfs_ioctl+0x1b/0x25
 [c10db157] ? do_vfs_ioctl+0x413/0x451
 [c10bdd69] ? do_mmap_pgoff+0x24c/0x2bf
 [c1048baa] ? up_write+0x16/0x2b
 [c10b07bd] ? vm_mmap_pgoff+0x57/0x73
 [c12fd68b] ? restore_all+0xf/0xf
 [c10db1d2] ? SyS_ioctl+0x3d/0x5b
 [c12fd658] ? syscall_call+0x7/0xb
=
[ INFO: inconsistent lock state ]
3.10.19 #1 Tainted: G   O
-
inconsistent 

[PATCH] sysctl: allow embedded targets to disable sysctl_check.c

[Holger Schurig]

Disable sysctl_check.c for embedded targets. This saves about about 11 kB
in .text and another 11 kB in .data on a PXA255 embedded platform.

Signed-off-by: Holger Schurig <[EMAIL PROTECTED]>

--- linux.orig/init/Kconfig
+++ linux/init/Kconfig
@@ -475,6 +475,17 @@
 
  If unsure say Y here.
 
+config SYSCTL_SYSCALL_CHECK
+   bool "Sysctl checks" if EMBEDDED
+   depends on SYSCTL_SYSCALL
+   default y
+   ---help---
+ sys_sysctl uses binary paths that have been found challenging
+ to properly maintain and use. This enables checks that help
+ you to keep things correct.
+
+ If unsure say Y here.
+
 config KALLSYMS
 bool "Load all symbols for debugging/ksymoops" if EMBEDDED
 default y
--- linux.orig/kernel/Makefile
+++ linux/kernel/Makefile
@@ -11,7 +11,7 @@
hrtimer.o rwsem.o nsproxy.o srcu.o \
utsname.o notifier.o ksysfs.o pm_qos_params.o
 
-obj-$(CONFIG_SYSCTL) += sysctl_check.o
+obj-$(CONFIG_SYSCTL_SYSCALL_CHECK) += sysctl_check.o
 obj-$(CONFIG_STACKTRACE) += stacktrace.o
 obj-y += time/
 obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -1604,9 +1604,13 @@
 
 static __init int sysctl_init(void)
 {
-   int err;
sysctl_set_parent(NULL, root_table);
-   err = sysctl_check_table(current->nsproxy, root_table);
+#ifdef CONFIG_SYSCTL_SYSCALL_CHECK
+   {
+   int err;
+   err = sysctl_check_table(current->nsproxy, root_table);
+   }
+#endif
return 0;
 }
 
@@ -1733,10 +1737,12 @@
header->unregistering = NULL;
header->root = root;
sysctl_set_parent(NULL, header->ctl_table);
+#ifdef CONFIG_SYSCTL_SYSCALL_CHECK
if (sysctl_check_table(namespaces, header->ctl_table)) {
kfree(header);
return NULL;
}
+#endif
spin_lock(_lock);
header_list = lookup_header_list(root, namespaces);
list_add_tail(>ctl_entry, header_list);
--
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: OOPS in sysctl.c

[Holger Schurig]

> erp.  We'd really like to know what we did to fix it, and then
> get that fix back into 2.6.24.x.

Agreed :-)


One more finding: after turning off CONFIG_SLUB and usng 
CONFIG_SLAB instead, I cannot reproduce the bug.

Also, a quite bit Qt-Embedded 3.x programm survives without any 
trouble the suspend/resume. So I think that I don't have a 
general memory corruption problem. This is however just a 
feeling, not an evidence.

--
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: OOPS in sysctl.c

[Holger Schurig]

On Wednesday 06 February 2008 20:03:53 you wrote:
> Please, post .config and "ls -lR /proc/sys" output _before_
> suspend/resume.

Just a note: I don't use vanilla v2.6.24, but v2.6.24 plus a 
bunch of patches on top of it. I minimized them and for v2.6.24, 
this is the minimal number of patches needed to get the device 
up & running and also supending & resuming:

$ quilt series
+ rt3000-core.patch
+ rt3000-defconfig.patch
+ rt3000-smc91x-mac.patch
+ mn-keyb.patch
+ mn-smc91x.patch
+ mn-suspend-ignore-console.patch
= ARM-pxa-fix-PXA27x-resume.patch

rt3000-core: this is the RT3000/RT4000 machine specific code, 
mostly in arch/arm/mach-pxa

rt3000-smc91x-mac.patch: code that put's a random MAC into the 
smc91x chip

mn-keyb.pm: my keyboard driver

mn-smc91x.patch: port and IRQ definitions for the SMC9 
ethernet chip

mn-suspend-ignore-console.patch: a patch for kernel/power/main.c 
that puts #if 0...#endif around all calls to 
pm_prepare_console(), pm_restore_console(), suspend_console() 
and resume_console(). Without this patch the device would hang 
while suspending.

ARM-pxa-fix-PXA27x-resume.patch: the same as "git show 
dd01b2fc79a567ae03d0c96ddf61eb4de729d36d" from linux-git. 
Without this patch, the device would hang while resuming.

I'm using the first 6 patches since 2.6.13-rc2, just with little 
updates to the changing API or changing Makefile/Kconfig files. 

When I apply exactly the same 6 patches to v2.6.24-7284-g9ef9dc6, 
then the OOPS doesn't happen. Therefore I assume that the 
culprit is not in one of these patches. It might just be 
important :-)
--
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: OOPS in sysctl.c

[Holger Schurig]

> Please, post .config and "ls -lR /proc/sys" output _before_
> suspend/resume.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Thu Feb  7 11:43:09 2008
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_ARCH_MTD_XIP=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=13
# CONFIG_CGROUPS is not set
# CONFIG_FAIR_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLABINFO=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=1
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_PNX4008 is not set
CONFIG_ARCH_PXA=y
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
CONFIG_ARCH_MN=y

#
# Intel PXA2xx/PXA3xx Implementations
#
# CONFIG_ARCH_LUBBOCK is not set
# CONFIG_MACH_LOGICPD_PXA270 is not set
# CONFIG_MACH_MAINSTONE is not set
# CONFIG_ARCH_PXA_IDP is not set
# CONFIG_PXA_SHARPSL is not set
# CONFIG_MACH_TRIZEPS4 is not set
# CONFIG_MACH_EM_X270 is not set
# CONFIG_MACH_ZYLONITE is not set
# CONFIG_MACH_ARMCORE is not set
CONFIG_MACH_RT3000=y
CONFIG_PXA25x=y

#
# Boot options
#

#
# Power management
#

#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_OUTER_CACHE is not set
# CONFIG_IWMMXT is not set
CONFIG_XSCALE_PMU=y

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
# CONFIG_PCMCIA_LOAD_CIS is not set
CONFIG_PCMCIA_IOCTL=y

#
# PC-card bridges
#
CONFIG_PCMCIA_PXA2XX=y

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_AEABI is not set
# 

Re: OOPS in sysctl.c

[Holger Schurig]

On Wednesday 06 February 2008 20:03:53 you wrote:
 Please, post .config and ls -lR /proc/sys output _before_
 suspend/resume.

Just a note: I don't use vanilla v2.6.24, but v2.6.24 plus a 
bunch of patches on top of it. I minimized them and for v2.6.24, 
this is the minimal number of patches needed to get the device 
up  running and also supending  resuming:

$ quilt series
+ rt3000-core.patch
+ rt3000-defconfig.patch
+ rt3000-smc91x-mac.patch
+ mn-keyb.patch
+ mn-smc91x.patch
+ mn-suspend-ignore-console.patch
= ARM-pxa-fix-PXA27x-resume.patch

rt3000-core: this is the RT3000/RT4000 machine specific code, 
mostly in arch/arm/mach-pxa

rt3000-smc91x-mac.patch: code that put's a random MAC into the 
smc91x chip

mn-keyb.pm: my keyboard driver

mn-smc91x.patch: port and IRQ definitions for the SMC9 
ethernet chip

mn-suspend-ignore-console.patch: a patch for kernel/power/main.c 
that puts #if 0...#endif around all calls to 
pm_prepare_console(), pm_restore_console(), suspend_console() 
and resume_console(). Without this patch the device would hang 
while suspending.

ARM-pxa-fix-PXA27x-resume.patch: the same as git show 
dd01b2fc79a567ae03d0c96ddf61eb4de729d36d from linux-git. 
Without this patch, the device would hang while resuming.

I'm using the first 6 patches since 2.6.13-rc2, just with little 
updates to the changing API or changing Makefile/Kconfig files. 

When I apply exactly the same 6 patches to v2.6.24-7284-g9ef9dc6, 
then the OOPS doesn't happen. Therefore I assume that the 
culprit is not in one of these patches. It might just be 
important :-)
--
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: OOPS in sysctl.c

[Holger Schurig]

 Please, post .config and ls -lR /proc/sys output _before_
 suspend/resume.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Thu Feb  7 11:43:09 2008
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_ARCH_MTD_XIP=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=13
# CONFIG_CGROUPS is not set
# CONFIG_FAIR_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLABINFO=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=1
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED=noop

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_PNX4008 is not set
CONFIG_ARCH_PXA=y
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
CONFIG_ARCH_MN=y

#
# Intel PXA2xx/PXA3xx Implementations
#
# CONFIG_ARCH_LUBBOCK is not set
# CONFIG_MACH_LOGICPD_PXA270 is not set
# CONFIG_MACH_MAINSTONE is not set
# CONFIG_ARCH_PXA_IDP is not set
# CONFIG_PXA_SHARPSL is not set
# CONFIG_MACH_TRIZEPS4 is not set
# CONFIG_MACH_EM_X270 is not set
# CONFIG_MACH_ZYLONITE is not set
# CONFIG_MACH_ARMCORE is not set
CONFIG_MACH_RT3000=y
CONFIG_PXA25x=y

#
# Boot options
#

#
# Power management
#

#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_OUTER_CACHE is not set
# CONFIG_IWMMXT is not set
CONFIG_XSCALE_PMU=y

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
# CONFIG_PCMCIA_LOAD_CIS is not set
CONFIG_PCMCIA_IOCTL=y

#
# PC-card bridges
#
CONFIG_PCMCIA_PXA2XX=y

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_AEABI is not set
# 

Re: OOPS in sysctl.c

[Holger Schurig]

 erp.  We'd really like to know what we did to fix it, and then
 get that fix back into 2.6.24.x.

Agreed :-)


One more finding: after turning off CONFIG_SLUB and usng 
CONFIG_SLAB instead, I cannot reproduce the bug.

Also, a quite bit Qt-Embedded 3.x programm survives without any 
trouble the suspend/resume. So I think that I don't have a 
general memory corruption problem. This is however just a 
feeling, not an evidence.

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

[PATCH] sysctl: allow embedded targets to disable sysctl_check.c

[Holger Schurig]

Disable sysctl_check.c for embedded targets. This saves about about 11 kB
in .text and another 11 kB in .data on a PXA255 embedded platform.

Signed-off-by: Holger Schurig [EMAIL PROTECTED]

--- linux.orig/init/Kconfig
+++ linux/init/Kconfig
@@ -475,6 +475,17 @@
 
  If unsure say Y here.
 
+config SYSCTL_SYSCALL_CHECK
+   bool Sysctl checks if EMBEDDED
+   depends on SYSCTL_SYSCALL
+   default y
+   ---help---
+ sys_sysctl uses binary paths that have been found challenging
+ to properly maintain and use. This enables checks that help
+ you to keep things correct.
+
+ If unsure say Y here.
+
 config KALLSYMS
 bool Load all symbols for debugging/ksymoops if EMBEDDED
 default y
--- linux.orig/kernel/Makefile
+++ linux/kernel/Makefile
@@ -11,7 +11,7 @@
hrtimer.o rwsem.o nsproxy.o srcu.o \
utsname.o notifier.o ksysfs.o pm_qos_params.o
 
-obj-$(CONFIG_SYSCTL) += sysctl_check.o
+obj-$(CONFIG_SYSCTL_SYSCALL_CHECK) += sysctl_check.o
 obj-$(CONFIG_STACKTRACE) += stacktrace.o
 obj-y += time/
 obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -1604,9 +1604,13 @@
 
 static __init int sysctl_init(void)
 {
-   int err;
sysctl_set_parent(NULL, root_table);
-   err = sysctl_check_table(current-nsproxy, root_table);
+#ifdef CONFIG_SYSCTL_SYSCALL_CHECK
+   {
+   int err;
+   err = sysctl_check_table(current-nsproxy, root_table);
+   }
+#endif
return 0;
 }
 
@@ -1733,10 +1737,12 @@
header-unregistering = NULL;
header-root = root;
sysctl_set_parent(NULL, header-ctl_table);
+#ifdef CONFIG_SYSCTL_SYSCALL_CHECK
if (sysctl_check_table(namespaces, header-ctl_table)) {
kfree(header);
return NULL;
}
+#endif
spin_lock(sysctl_lock);
header_list = lookup_header_list(root, namespaces);
list_add_tail(header-ctl_entry, header_list);
--
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: kara_am

[Holger Schurig]

am kara wrote:

> I have a suggestion for the documentation of the
> kernel. Placing a comment about the function of each
> file and folder inside the kernel.
> 
> This comment maybe short but saves a lot of time of a
> code reviewer.

I have a suggestion for the documentation of e-mails.
Use a proper subject for each message, and not always
the same subject.


--
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: OOPS in sysctl.c

[Holger Schurig]

> I have an embedded target (PXA255 based) where I have a nice
> running kernel 2.6.15. Today I'm trying to get 2.6.24 running
> on it.

Whatever the problem is, sysfs works now flawlessly even after
a suspend/resume with v2.6.24-7284-g9ef9dc6.
--
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/

OOPS in sysctl.c

[Holger Schurig]

I have an embedded target (PXA255 based) where I have a nice
running kernel 2.6.15. Today I'm trying to get 2.6.24 running on
it. To get suspend/resume working, I had to add a patch from the
current development kernel, but after this things seemed to work
fine.

Unfortunately I can reproducibly trigger an OOPS. When I do
"ls /proc/sys" AFTER I suspended/resumed, I get this:

# ls /proc/sys
Unable to handle kernel NULL pointer dereference at virtual address 000c
pgd = c3e14000
[000c] *pgd=a3e22031, *pte=, *ppte=
Internal error: Oops: 17 [#1]
Modules linked in:
CPU: 0Not tainted  (2.6.24 #41)
PC is at sysctl_head_next+0x28/0x64
LR is at sysctl_head_next+0x20/0x64
pc : []lr : []psr: 0013
sp : c3e1bed0  ip : c3e1bed0  fp : c3e1bee0
r10: c3cfec00  r9 :   r8 : 
r7 : c3e1bf14  r6 : c384ea2c  r5 :   r4 : 
r3 : c01f6ffc  r2 : fffc  r1 :   r0 : 
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 397f  Table: a3e14000  DAC: 0015
Process ls (pid: 302, stack limit = 0xc3e1a258)
Stack: (0xc3e1bed0 to 0xc3e1c000)
bec0:  c3e1bf48 c3e1bee4 c00a4b80
bee0: c0038bc8  008f  0004 c3cfec20  000d
bf00: c3c02540 c384ea2c c007cc08 c3e1bf74 c01f6ff8 00272c85 0003 c01c9ef8
bf20: c3cfec00 c3845470 fffe c3e1bf74 c007cc08 c3e1a000 c38454d8 c3e1bf70
bf40: c3e1bf4c c007c860 c00a482c 00099128  0400 fff7 c3cfec00
bf60: 40221000 c3e1bfa4 c3e1bf74 c007cdf0 c007c7fc 000991f8 000991e0 0330
bf80: ffea 0e58  0e68 00d9 c0024004  c3e1bfa8
bfa0: c0023e60 c007cd90 0e58  0003 00099128 0400 00099128
bfc0: 0e58  0e68  0400  40221000 bea9ed44
bfe0: 402232bc bea9ecf8 40196314 40196348 2010 0003  
Backtrace:
[] (sysctl_head_next+0x0/0x64) from [] 
(proc_sys_readdir+0x360/0x394)
 r4:
[] (proc_sys_readdir+0x0/0x394) from [] 
(vfs_readdir+0x70/0x98)
[] (vfs_readdir+0x0/0x98) from [] (sys_getdents64+0x6c/0xc0)
[] (sys_getdents64+0x0/0xc0) from [] 
(ret_fast_syscall+0x0/0x2c)
 r8:c0024004 r7:00d9 r6:0e68 r5: r4:0e58
Code: e2834004 ebe5 ea08 e2442004 (e5923010)
---[ end trace e5f1dfd5727fedd3 ]---
Segmentation fault


Before suspend/resume the "ls /proc/sys" works as
expected. I tried to find the root cause, but could
so far only find a bandaid:

--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -1320,6 +1320,8 @@
return head;
next:
tmp = tmp->next;
+   if (tmp == NULL)
+   break;
if (tmp == _table_header.ctl_entry)
break;
}

Now the OOPS is gone. However, two problems remain:

* why the was the linked list thrashed in the first place?
* where are the missing file entries?

Because some entries are missing:

$ find /proc/sys >a
$ echo mem >/sys/power/state
$ find /proc/sys >b
$ diff a b
--- a   2008-02-04 15:36:36.0 +0100
+++ b   2008-02-04 15:36:36.0 +0100
@@ -26,20 +26,6 @@
 /proc/sys/kernel/randomize_va_space
 /proc/sys/kernel/maps_protect
 /proc/sys/kernel/poweroff_cmd
-/proc/sys/kernel/ostype
-/proc/sys/kernel/osrelease
-/proc/sys/kernel/version
-/proc/sys/kernel/hostname
-/proc/sys/kernel/domainname
-/proc/sys/kernel/shmmax
-/proc/sys/kernel/shmall
-/proc/sys/kernel/shmmni
-/proc/sys/kernel/msgmax
-/proc/sys/kernel/msgmni
-/proc/sys/kernel/msgmnb
-/proc/sys/kernel/sem
-/proc/sys/kernel/pty/max
-/proc/sys/kernel/pty/nr
 /proc/sys/vm/overcommit_memory
 /proc/sys/vm/panic_on_oom
 /proc/sys/vm/oom_kill_allocating_task
@@ -190,20 +176,6 @@
 /proc/sys/net/ipv4/neigh/lo/locktime
 /proc/sys/net/ipv4/neigh/lo/retrans_time_ms
 /proc/sys/net/ipv4/neigh/lo/base_reachable_time_ms
-/proc/sys/net/ipv4/neigh/eth0/mcast_solicit
-/proc/sys/net/ipv4/neigh/eth0/ucast_solicit
-/proc/sys/net/ipv4/neigh/eth0/app_solicit
-/proc/sys/net/ipv4/neigh/eth0/retrans_time
-/proc/sys/net/ipv4/neigh/eth0/base_reachable_time
-/proc/sys/net/ipv4/neigh/eth0/delay_first_probe_time
-/proc/sys/net/ipv4/neigh/eth0/gc_stale_time
-/proc/sys/net/ipv4/neigh/eth0/unres_qlen
-/proc/sys/net/ipv4/neigh/eth0/proxy_qlen
-/proc/sys/net/ipv4/neigh/eth0/anycast_delay
-/proc/sys/net/ipv4/neigh/eth0/proxy_delay
-/proc/sys/net/ipv4/neigh/eth0/locktime
-/proc/sys/net/ipv4/neigh/eth0/retrans_time_ms
-/proc/sys/net/ipv4/neigh/eth0/base_reachable_time_ms
 /proc/sys/net/ipv4/conf/lo/forwarding
 /proc/sys/net/ipv4/conf/lo/mc_forwarding
 /proc/sys/net/ipv4/conf/lo/accept_redirects
@@ -267,28 +239,6 @@
 /proc/sys/net/ipv4/conf/default/disable_policy
 /proc/sys/net/ipv4/conf/default/force_igmp_version
 /proc/sys/net/ipv4/conf/default/promote_secondaries
-/proc/sys/net/ipv4/conf/eth0/forwarding
-/proc/sys/net/ipv4/conf/eth0/mc_forwarding
-/proc/sys/net/ipv4/conf/eth0/accept_redirects

OOPS in sysctl.c

[Holger Schurig]

I have an embedded target (PXA255 based) where I have a nice
running kernel 2.6.15. Today I'm trying to get 2.6.24 running on
it. To get suspend/resume working, I had to add a patch from the
current development kernel, but after this things seemed to work
fine.

Unfortunately I can reproducibly trigger an OOPS. When I do
ls /proc/sys AFTER I suspended/resumed, I get this:

# ls /proc/sys
Unable to handle kernel NULL pointer dereference at virtual address 000c
pgd = c3e14000
[000c] *pgd=a3e22031, *pte=, *ppte=
Internal error: Oops: 17 [#1]
Modules linked in:
CPU: 0Not tainted  (2.6.24 #41)
PC is at sysctl_head_next+0x28/0x64
LR is at sysctl_head_next+0x20/0x64
pc : [c0038be4]lr : [c0038bdc]psr: 0013
sp : c3e1bed0  ip : c3e1bed0  fp : c3e1bee0
r10: c3cfec00  r9 :   r8 : 
r7 : c3e1bf14  r6 : c384ea2c  r5 :   r4 : 
r3 : c01f6ffc  r2 : fffc  r1 :   r0 : 
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 397f  Table: a3e14000  DAC: 0015
Process ls (pid: 302, stack limit = 0xc3e1a258)
Stack: (0xc3e1bed0 to 0xc3e1c000)
bec0:  c3e1bf48 c3e1bee4 c00a4b80
bee0: c0038bc8  008f  0004 c3cfec20  000d
bf00: c3c02540 c384ea2c c007cc08 c3e1bf74 c01f6ff8 00272c85 0003 c01c9ef8
bf20: c3cfec00 c3845470 fffe c3e1bf74 c007cc08 c3e1a000 c38454d8 c3e1bf70
bf40: c3e1bf4c c007c860 c00a482c 00099128  0400 fff7 c3cfec00
bf60: 40221000 c3e1bfa4 c3e1bf74 c007cdf0 c007c7fc 000991f8 000991e0 0330
bf80: ffea 0e58  0e68 00d9 c0024004  c3e1bfa8
bfa0: c0023e60 c007cd90 0e58  0003 00099128 0400 00099128
bfc0: 0e58  0e68  0400  40221000 bea9ed44
bfe0: 402232bc bea9ecf8 40196314 40196348 2010 0003  
Backtrace:
[c0038bbc] (sysctl_head_next+0x0/0x64) from [c00a4b80] 
(proc_sys_readdir+0x360/0x394)
 r4:
[c00a4820] (proc_sys_readdir+0x0/0x394) from [c007c860] 
(vfs_readdir+0x70/0x98)
[c007c7f0] (vfs_readdir+0x0/0x98) from [c007cdf0] (sys_getdents64+0x6c/0xc0)
[c007cd84] (sys_getdents64+0x0/0xc0) from [c0023e60] 
(ret_fast_syscall+0x0/0x2c)
 r8:c0024004 r7:00d9 r6:0e68 r5: r4:0e58
Code: e2834004 ebe5 ea08 e2442004 (e5923010)
---[ end trace e5f1dfd5727fedd3 ]---
Segmentation fault


Before suspend/resume the ls /proc/sys works as
expected. I tried to find the root cause, but could
so far only find a bandaid:

--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -1320,6 +1320,8 @@
return head;
next:
tmp = tmp-next;
+   if (tmp == NULL)
+   break;
if (tmp == root_table_header.ctl_entry)
break;
}

Now the OOPS is gone. However, two problems remain:

* why the was the linked list thrashed in the first place?
* where are the missing file entries?

Because some entries are missing:

$ find /proc/sys a
$ echo mem /sys/power/state
$ find /proc/sys b
$ diff a b
--- a   2008-02-04 15:36:36.0 +0100
+++ b   2008-02-04 15:36:36.0 +0100
@@ -26,20 +26,6 @@
 /proc/sys/kernel/randomize_va_space
 /proc/sys/kernel/maps_protect
 /proc/sys/kernel/poweroff_cmd
-/proc/sys/kernel/ostype
-/proc/sys/kernel/osrelease
-/proc/sys/kernel/version
-/proc/sys/kernel/hostname
-/proc/sys/kernel/domainname
-/proc/sys/kernel/shmmax
-/proc/sys/kernel/shmall
-/proc/sys/kernel/shmmni
-/proc/sys/kernel/msgmax
-/proc/sys/kernel/msgmni
-/proc/sys/kernel/msgmnb
-/proc/sys/kernel/sem
-/proc/sys/kernel/pty/max
-/proc/sys/kernel/pty/nr
 /proc/sys/vm/overcommit_memory
 /proc/sys/vm/panic_on_oom
 /proc/sys/vm/oom_kill_allocating_task
@@ -190,20 +176,6 @@
 /proc/sys/net/ipv4/neigh/lo/locktime
 /proc/sys/net/ipv4/neigh/lo/retrans_time_ms
 /proc/sys/net/ipv4/neigh/lo/base_reachable_time_ms
-/proc/sys/net/ipv4/neigh/eth0/mcast_solicit
-/proc/sys/net/ipv4/neigh/eth0/ucast_solicit
-/proc/sys/net/ipv4/neigh/eth0/app_solicit
-/proc/sys/net/ipv4/neigh/eth0/retrans_time
-/proc/sys/net/ipv4/neigh/eth0/base_reachable_time
-/proc/sys/net/ipv4/neigh/eth0/delay_first_probe_time
-/proc/sys/net/ipv4/neigh/eth0/gc_stale_time
-/proc/sys/net/ipv4/neigh/eth0/unres_qlen
-/proc/sys/net/ipv4/neigh/eth0/proxy_qlen
-/proc/sys/net/ipv4/neigh/eth0/anycast_delay
-/proc/sys/net/ipv4/neigh/eth0/proxy_delay
-/proc/sys/net/ipv4/neigh/eth0/locktime
-/proc/sys/net/ipv4/neigh/eth0/retrans_time_ms
-/proc/sys/net/ipv4/neigh/eth0/base_reachable_time_ms
 /proc/sys/net/ipv4/conf/lo/forwarding
 /proc/sys/net/ipv4/conf/lo/mc_forwarding
 /proc/sys/net/ipv4/conf/lo/accept_redirects
@@ -267,28 +239,6 @@
 /proc/sys/net/ipv4/conf/default/disable_policy
 /proc/sys/net/ipv4/conf/default/force_igmp_version
 /proc/sys/net/ipv4/conf/default/promote_secondaries
-/proc/sys/net/ipv4/conf/eth0/forwarding

Re: OOPS in sysctl.c

[Holger Schurig]

 I have an embedded target (PXA255 based) where I have a nice
 running kernel 2.6.15. Today I'm trying to get 2.6.24 running
 on it.

Whatever the problem is, sysfs works now flawlessly even after
a suspend/resume with v2.6.24-7284-g9ef9dc6.
--
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: kara_am

[Holger Schurig]

am kara wrote:

 I have a suggestion for the documentation of the
 kernel. Placing a comment about the function of each
 file and folder inside the kernel.
 
 This comment maybe short but saves a lot of time of a
 code reviewer.

I have a suggestion for the documentation of e-mails.
Use a proper subject for each message, and not always
the same subject.


--
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 3/3] wireless/libertas: don't cast a pointer to pointer of list_head

[Holger Schurig]

> BTW: I'm not so sure where this patch should go to.

To <[EMAIL PROTECTED]>, as Dan Williams (libertas 
maintainer) monitors this list.

The wireless development tree is wireless-2.6, branch everything. 
You patch doesn't apply to this tree currently, but it's easy to 
fix. I'll bring it in shape, and resubmit.




As a side note: if you want to make comments, put them below --- 
under your Signed-off-by line. Your "BTW"-Line would have ended 
up in the output of "git log".



libertas: fixes blah mumpf worps

This fixes the worps feature.

Signed-of-by: Donald Duck <[EMAIL PROTECTED]>

---
Here you can put any comments about your patch that should not 
end up in the history of git that you can see with "git log".

[patch comes here]
--
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 3/3] wireless/libertas: don't cast a pointer to pointer of list_head

[Holger Schurig]

 BTW: I'm not so sure where this patch should go to.

To [EMAIL PROTECTED], as Dan Williams (libertas 
maintainer) monitors this list.

The wireless development tree is wireless-2.6, branch everything. 
You patch doesn't apply to this tree currently, but it's easy to 
fix. I'll bring it in shape, and resubmit.




As a side note: if you want to make comments, put them below --- 
under your Signed-off-by line. Your BTW-Line would have ended 
up in the output of git log.



libertas: fixes blah mumpf worps

This fixes the worps feature.

Signed-of-by: Donald Duck [EMAIL PROTECTED]

---
Here you can put any comments about your patch that should not 
end up in the history of git that you can see with git log.

[patch comes here]
--
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/

bug in checkpath.pl

[Holger Schurig]

I have a case where scripts/checkpatch.pl returns a false error. 
First, here is the code:


static int lbs_scan_add_rates_tlv(u8 *tlv)
{
int i;
struct mrvlietypes_ratesparamset *rate_tlv =
(struct mrvlietypes_ratesparamset *) tlv;

rate_tlv->header.type = cpu_to_le16(TLV_TYPE_RATES);
tlv += sizeof(rate_tlv->header);
for (i = 0; i < MAX_RATES; i++) {
*tlv = lbs_bg_rates[i];
if (*tlv == 0)
break;
if (*tlv == 0x02 || *tlv == 0x04 ||
*tlv == 0x0b || *tlv == 0x16)
*tlv |= 0x80;
tlv++;
}
rate_tlv->header.len = i;
return sizeof(rate_tlv->header) + i;
}


And here the error from checkpatch.pl:

ERROR: need consistent spacing around '*' (ctx:WxV)
#553: FILE: drivers/net/wireless/libertas/scan.c:438:
+   *tlv |= 0x80;



This error seems wrong, tlv is a pointer to some u8 value
(a.k.a. unsigned char), and it is very well allowed to
operate on it via *variablename |= 0x80;
-
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/

bug in checkpath.pl

[Holger Schurig]

I have a case where scripts/checkpatch.pl returns a false error. 
First, here is the code:


static int lbs_scan_add_rates_tlv(u8 *tlv)
{
int i;
struct mrvlietypes_ratesparamset *rate_tlv =
(struct mrvlietypes_ratesparamset *) tlv;

rate_tlv-header.type = cpu_to_le16(TLV_TYPE_RATES);
tlv += sizeof(rate_tlv-header);
for (i = 0; i  MAX_RATES; i++) {
*tlv = lbs_bg_rates[i];
if (*tlv == 0)
break;
if (*tlv == 0x02 || *tlv == 0x04 ||
*tlv == 0x0b || *tlv == 0x16)
*tlv |= 0x80;
tlv++;
}
rate_tlv-header.len = i;
return sizeof(rate_tlv-header) + i;
}


And here the error from checkpatch.pl:

ERROR: need consistent spacing around '*' (ctx:WxV)
#553: FILE: drivers/net/wireless/libertas/scan.c:438:
+   *tlv |= 0x80;



This error seems wrong, tlv is a pointer to some u8 value
(a.k.a. unsigned char), and it is very well allowed to
operate on it via *variablename |= 0x80;
-
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] Remove pointless casts from void pointers,

[Holger Schurig]

>  drivers/net/wireless/libertas/if_cs.c  |2 +-

ACK
-
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] Remove pointless casts from void pointers,

[Holger Schurig]

  drivers/net/wireless/libertas/if_cs.c  |2 +-

ACK
-
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: drivers/net/wireless/libertas/rx.c: use-after-free

[Holger Schurig]

libertas: remove a coverity bug

... by removing an ill-conceived, useless line.

Signed-off-by: Holger Schurig <[EMAIL PROTECTED]>

---

Dunno how this line made it into the patch that I made in
February and was commited in May. At that time, I didn't hardly
knew anything about skb's at all and certainly didn't play with
raw ethernet types. Maybe it was a remnant of some bugus test
that I or the committer did?!?

I tested the driver after the removal of this line with ping and
ssh, but not anything else (e.g. no mesh, no tshark monitoring).

 drivers/net/wireless/libertas/rx.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/libertas/rx.c 
b/drivers/net/wireless/libertas/rx.c
index 88d9d2d..769c86f 100644
--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -439,7 +439,6 @@ static int process_rxed_802_11_packet(wlan_private * priv, 
struct sk_buff *skb)
ret = 0;
 
 done:
-   skb->protocol = __constant_htons(0x0019);   /* ETH_P_80211_RAW */
lbs_deb_leave_args(LBS_DEB_RX, "ret %d", ret);
return ret;
 }
-
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: drivers/net/wireless/libertas/rx.c: use-after-free

[Holger Schurig]

libertas: remove a coverity bug

... by removing an ill-conceived, useless line.

Signed-off-by: Holger Schurig [EMAIL PROTECTED]

---

Dunno how this line made it into the patch that I made in
February and was commited in May. At that time, I didn't hardly
knew anything about skb's at all and certainly didn't play with
raw ethernet types. Maybe it was a remnant of some bugus test
that I or the committer did?!?

I tested the driver after the removal of this line with ping and
ssh, but not anything else (e.g. no mesh, no tshark monitoring).

 drivers/net/wireless/libertas/rx.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/libertas/rx.c 
b/drivers/net/wireless/libertas/rx.c
index 88d9d2d..769c86f 100644
--- a/drivers/net/wireless/libertas/rx.c
+++ b/drivers/net/wireless/libertas/rx.c
@@ -439,7 +439,6 @@ static int process_rxed_802_11_packet(wlan_private * priv, 
struct sk_buff *skb)
ret = 0;
 
 done:
-   skb-protocol = __constant_htons(0x0019);   /* ETH_P_80211_RAW */
lbs_deb_leave_args(LBS_DEB_RX, ret %d, ret);
return ret;
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.

[Holger Schurig]

> After the reset, I got a 0x06 0x00 back, which is fine.
>
> But when the driver sets the coordinate output rate, the
> TSC-103 answered 0x15 0x01 which means that the TSC-10 is used
> with an EEPROM but the EEPROM data is empty (which is
> correct).
>
> In that case the driver should at least continue to allow
> initialization of the EEPROM later on.

No, I don't think so. Not in it's current form.


Currently, usbtouchscreen doesn't have any means to initialize an 
EEPROM. And in the absence of such a possibility, you need other 
means to accomplish your task. The current behavior provides you 
with this "plan b":

If you set the rate and that doesn't work because no EEPROM is 
there, the driver fails. While doing it, it will release the 
device.

This brings in the opportunity to access the touchscreen 
controller from userspace, e.g. with libusb, and write the 
EEPROM. After this, reboot, and be happy. Because now the device 
would act correctly on the "set rate" command and would be 
usable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type->init() failed.

[Holger Schurig]

> The same is true if there is no EEPROM present but the EEPROM
> is enabled. Anyway, I disabled my EEPROM by pulling the SEL4
> pin high because I don't need/want it (yet).

The same is done by my hardware guy. In my case, there is no 
EEPROM attached ... but he didn't pull up this pin up, until I 
found out what happend.

For the EEPROM: I actually don't care if the calibration data is 
written somewhere in my filesystem or in some proprietary 
EEPROM. If you create gadgets with unwritable filesystems, e.g. 
cramfs, then you might care. But I didn't, and therefore didn't 
bother implementing any support for calibration on the 
driver-level. I'm doing that completely from userspace.



> I started to do some more error handling, but it's propably
> not worth doing so if the driver(s) has only limited
> functionality (and no userspace app using it).

Who says that the driver has no user space app?  All touchscreen 
events that you get are exported via /dev/input/eventX to user 
space and there are plenty of apps that utilize this info.

I wrote a (company inside) tool that reads /dev/input/eventXX, 
calibrates them and injects those events into X11 via the XTest 
extension. But for newer X.Org release you can also use 
xserver-input-event driver. My approach has just the benefit 
that I can "SIGHUP" my driver any time to re-calibrate, I don't 
need to restart X for this, which is cumbersome.


So, please add error handling and post your patch :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type-init() failed.

[Holger Schurig]

 The same is true if there is no EEPROM present but the EEPROM
 is enabled. Anyway, I disabled my EEPROM by pulling the SEL4
 pin high because I don't need/want it (yet).

The same is done by my hardware guy. In my case, there is no 
EEPROM attached ... but he didn't pull up this pin up, until I 
found out what happend.

For the EEPROM: I actually don't care if the calibration data is 
written somewhere in my filesystem or in some proprietary 
EEPROM. If you create gadgets with unwritable filesystems, e.g. 
cramfs, then you might care. But I didn't, and therefore didn't 
bother implementing any support for calibration on the 
driver-level. I'm doing that completely from userspace.



 I started to do some more error handling, but it's propably
 not worth doing so if the driver(s) has only limited
 functionality (and no userspace app using it).

Who says that the driver has no user space app?  All touchscreen 
events that you get are exported via /dev/input/eventX to user 
space and there are plenty of apps that utilize this info.

I wrote a (company inside) tool that reads /dev/input/eventXX, 
calibrates them and injects those events into X11 via the XTest 
extension. But for newer X.Org release you can also use 
xserver-input-event driver. My approach has just the benefit 
that I can SIGHUP my driver any time to re-calibrate, I don't 
need to restart X for this, which is cumbersome.


So, please add error handling and post your patch :-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21.5: BUG: usbtouchscreen.c DMC TSC-10 wrong descriptor type / type-init() failed.

[Holger Schurig]

 After the reset, I got a 0x06 0x00 back, which is fine.

 But when the driver sets the coordinate output rate, the
 TSC-103 answered 0x15 0x01 which means that the TSC-10 is used
 with an EEPROM but the EEPROM data is empty (which is
 correct).

 In that case the driver should at least continue to allow
 initialization of the EEPROM later on.

No, I don't think so. Not in it's current form.


Currently, usbtouchscreen doesn't have any means to initialize an 
EEPROM. And in the absence of such a possibility, you need other 
means to accomplish your task. The current behavior provides you 
with this plan b:

If you set the rate and that doesn't work because no EEPROM is 
there, the driver fails. While doing it, it will release the 
device.

This brings in the opportunity to access the touchscreen 
controller from userspace, e.g. with libusb, and write the 
EEPROM. After this, reboot, and be happy. Because now the device 
would act correctly on the set rate command and would be 
usable.
-
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/