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 outco
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 diff
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
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
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
> 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 thin
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
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
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
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.
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 Bareb
> (Interestingly, it also blinks the LEDs on a USB keyboard!)
Assuming USB is still working after a kernel panic ...
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
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
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 derive
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
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 th
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
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
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?
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
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(
> 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
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
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.
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
. 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
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
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/
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
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 in
> 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
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 ...
> 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-fi
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
#
> 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 bo
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 contro
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
> 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
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 ne
> 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_GENERI
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 pro
> 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 "unsub
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 tri
> 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
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 = cp
> 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/
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&#
> 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 con
> 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
> Independent of any nl80211 status the private libertas ioctls have to
> go. Not only don't we want private ioctls for mesh networking but
> rather have it as driver-independent interface, but the actual
> libertas interface is the worst possible choice.
I have been told that the Libertas mesh f
I have an AdvanTech PCM-9381 board and noticed in dmesg that I should add
"pci=assign-busses" and report this to linux-kernel. Knowing nothing about
the underlying problem (and not even sure that there is a problem), I'm
just concur :-)
"lspci -t" show the same output with and without "pci=assign-
Fixes warning: 'sw_any_bug_dmi_table' defined but not used
Signed-off-by: Holger Schurig <[EMAIL PROTECTED]>
--- linux.orig/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
@@ -385,6 +385,7 @@
* detected, this has
> I believe tslib handles this.
The special X server "KDrive" supports tslib, this is used in
many embedded projects, e.g. by images created via
http://www.openembedded.org. But mainline X.org server, e.g.
what is in Debian unstable (7.1.0), doesn't support tslib.
Also I don't know if X/tslib
Basic support support for the USB-based DMC TSC-10
touchscreen controller.
Signed-off-by: Holger Schurig <[EMAIL PROTECTED]>
---
Changelog:
* mentioned where I got tooks ideas from (unmerged code
from Marius Vollmer)
* mentioned DMC TSC-25 as well
* sorted device list alphabetically (b
> sorry, but i have to give you a big NACK on that one:
Hehe, I actually anticipated this NACK :-)
> - no more modparam: it should be per-device sysfs attributes
> (swap_xy is basically only for touchkitusb compatibility and
>shoud be converted to per-device sysfs attribute as well. i
>
From: Holger Schurig <[EMAIL PROTECTED]>
Generic calibration support for usbtouchscreen.
Signed-off-by: Holger Schurig <[EMAIL PROTECTED]>
---
With build-in calibration support, the "swap_xy" kernel parameter
vanishes and usbtouchscreen instead gains a new kernel-p
From: Holger Schurig <[EMAIL PROTECTED]>
Basic support support for the USB-based DMC TSC-10 touchscreen
controller.
Signed-off-by: Holger Schrig <[EMAIL PROTECTED]>
---
The previous patch was word-wrapped, sorry.
Please review this patch and schedule it for inclusion once
2.6.
From: Holger Schurig <[EMAIL PROTECTED]>
Basic support support for the USB-based DMC TSC-10 touchscreen
controller.
Signed-off-by: Holger Schrig <[EMAIL PROTECTED]>
---
Please review this patch and schedule it for inclusion once
2.6.19 comes out.
The DMC TSC-10 come
59 matches
Mail list logo
