ere in the kernel.
Could someone please explain and repair the magic that is happening here?
Thanks in advance, Wim Osterholt.
- w...@djo.tudelft.nl -
On Sat, Jun 11, 2016 at 02:15:01PM +0100, One Thousand Gnomes wrote:
> > open(/dev/fd0, O_ACCMODE) = -1
> If you do
>
> touch foo
>
> then compile and run the following program does it error on the newer
> kernel ?
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> if
On Mon, Jun 13, 2016 at 02:15:15PM +0200, Jiri Kosina wrote:
> > up to vanilla kernel 4.4.13 floppy functionality performs like it should.
> > (On an x86 PC that is. With a 1.44MB diskette drive.)
> > >From kernel 4.5* and up it changed to barely usable.
> >
> > After a virgin start (cold or
On Wed, Jun 15, 2016 at 09:09:13AM +0200, Jiri Kosina wrote:
> > Surprising or not, the thusly compiled kernel ran fine and I could
> > handle floppies like before! (open(/dev/fd0,O_ACCMODE) succeeds.)
>
> Thanks for testing.
>
> Now next question -- what do you actually want to achieve with
> Can you try the following and see if it makes any difference?
>
>
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
> int penalty = 0;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - penalty +=
On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote:
>
> Thanks, It was a guess with no proof.
>
> Let's undo the change above and start adding some print statements to collect
> data from your system.
>
> Can you add this to the end of acpi_irq_get_penalty function and then send
> the
L.S.
up to vanilla kernel-4.6.2 sound was working fine.
Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc.
There appears to be a bug in the Intel sound driver and/or ACPI driver.
Dmesg shows interesting lines like:
[ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> On 2016-06-21 18:13, Wim Osterholt wrote:
> >>
> >>pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> >>penalty);
> >>
> >
> >
On my first message I stated:
It looks to me that the code in floppy.c is quite old; no changes here.
So the bug is elsewhere in the kernel.
That was because the changelog at the beginning of floppy.c ended in 2003.
Wouln't it be wise to keep these items updated?
Groeten, Wim.
-
On Wed, Jun 15, 2016 at 04:13:53PM +0200, Jiri Kosina wrote:
>
> Wim, could you please test whether the patch below, applied on top of
> vanilla kernel (i.e. drop the revert), everything you are using still
> works as expected?
>
Applied on kernel-4.7-rc3 it looks like it's working. (Strace
On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
> >
> > Sure, let me get a patch for you.
>
> Here it is
http://webserver.djo.tudelft.nl/dmesg460+printpatch2
> I am trying to find a system with similar characteristics for debug
All from the same laptop, Dell Inspiron 4100.
The
On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote:
>
> Can you give it a try?
Whell, I tried to no avail.
Wether it is on 4.6 or 4.7, with or without your previous patch,
I keep getting rejected hunks.
For example, here the line to be deleted is nowhere to be found:
> diff --git
On Sat, Jun 25, 2016 at 04:51:03AM -0400, ok...@codeaurora.org wrote:
> On 2016-06-24 21:39, Wim Osterholt wrote:
>
> Please apply the patches on top of clean 4.7-rc4 tree and apply them in
> order with
>
> git am 0001...
> git am 0002...
It doesn't work that way.
Beginn
ed setfdprm userspace for ioctl-only open().
>
> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
> modes, while still keeping the original O_NDELAY bug fixed.
>
> Cc: sta...@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt <w...@djo.tudelft.nl>
&g
On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote:
> > However, an earlier try on my Inspiron 510m did not work.
> > I'll do a clean retry later today, just to make sure.
>
>
> Ok, let me know. I can post a clean patch series. I was trying to get
> you something to test
t is quite similar to the one from kernel-4.6 .
Tested-by: Wim Osterholt. <w...@djo.tudelft.nl>
, but it says
null pointer dereference at 0246
...
failed while handling devices/pci:00/:00:1d.3/usb7/7-1/7-1:1d etc.
...
udevd .. is taking too long..
Could someone please explain and repair the magic that is happening here?
Thanks in advance, Wim Osterholt.
- w...@djo.tudelft.nl -
On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> >
> > The oops tells things that I didn't all write down, but it says
> > null pointer dereference at 0246
>
> That is the important part. I am sorry, but without the oops
> nobody can help you. Please capture it
Sep 6
On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep 6 19:12:38 localhost kernel: Call Trace:
> > Sep 6 19:12:38 localhost kernel: [] ? 0xc01f4347
>
> Hi,
>
> your stack trace is broken. Did you fail to install the System.map file?
Never needed that for anything the last 20
On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep 6 19:12:38 localhost kernel: Call Trace:
> > Sep 6 19:12:38 localhost kernel: [] ? 0xc01f4347
>
> Hi,
>
> your stack trace is broken. Did you fail to install the System.map file?
Source is available under /usr/src/linux
> your stack trace is broken. Did you fail to install the System.map file?
>
> Regards
> Oliver
>Finally found something.
>CONFIG_DEBUG_INFO was not set.
Doesn't make any difference either.
Compiled cdc_acm in the kernel, not as a module. Doesn't make any
difference, except
On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
>
> your stack trace is broken. Did you fail to install the System.map file?
>
> Regards
> Oliver
A laptop, more broken than the rest, does not output anything after
inserting. Later on it crashes. No system.map
On Wed, Sep 28, 2016 at 05:23:30PM +0200, Oliver Neukum wrote:
> >
> > HP src # sync
> > HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer
> > dereference at 0249
>
> The last view lines before that please with the debugging level ramped
> up to 9 please.
Recompiled again,
On Wed, Sep 28, 2016 at 07:38:41PM -0400, Sinan Kaya wrote:
>
> Can you try these patches on your machines please?
I applied the included patches on vanilla 4.8-rc8 and my machine booted
fine. (I saw a remark about SCSI interrupts, but I have no SCSI.)
Regards, Wim.
On Tue, Sep 20, 2016 at 03:05:14PM +0200, Oliver Neukum wrote:
>
> I cannot replicate it. Could you please provide "lsusb -v"?
>
> Regards
> Oliver
It concerns these type of modems:
http://www.ebay.nl/itm/191933738340
http://www.ebay.nl/itm/121590899044
lsusb:
Bus 002
On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> On Tue, 2016-09-20 at 17:45 +0200, Wim Osterholt wrote:
>
> Anyway, which of its configurations is used?
> Please look up the bConfigurationValue for your device
> in sysfs.
And what might that be?
'locate sysfs
On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> in sysfs.
Google pointed me to /sys/bus/usb/drivers/usb/*
where I find all kinds of 'bConfigurationValue'.
Now is the problem to find which one you could mean.
Under /sys/bus/usb/drivers/usb/7-1 I find
manufacturer which reads
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
>
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
>
> [plug your device in]
>
> and provide the full output of dmesg after that.
That is not
> >Please look up the bConfigurationValue for your device
> >in sysfs.
I didn't explicitly say that this was done under kernel-4.7.4, otherwise
it may have been impossible under 4.8 .
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
>
> OK. Strange. Please do
>
> dmesg -c
>
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> OK. Strange. Please do
>
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
>
> [plug your device in]
>
> and provide the full output of dmesg after
On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
> this should show you where it crashes. In addition I've attached
> a patch with paranoid debugging. Could you compile and test a kernel
> with it?
>
> Regards
> Oliver
If you mean
echo "module cdc_acm +mpf" >
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
>
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
>
> [plug your device in]
>
> and provide the full output of dmesg after that.
After some
On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
>
> Very good. This is a valid oops. We can do two things. When I
> decode it, seems to crash in acm_alloc_minor() which does not make
> sense. It is likely that our kernels or compilers are a bit different.
> Could you please call
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> On Mon, 2016-10-17 at 17:20 +0200, Wim Osterholt wrote:
> > On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> > > Hi,
> > >
> > > I got one of those devices. However, I don't
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: Manufacturer: Conexant
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: SerialNumber: 12345678
With that unique serial number it must be that very device. :-)
> It definitely does
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> It definitely does not crash and is probed and your .config is not
> extremely unusual.
Hmmm.
> ... Something odd is going on.
Whell, yes.
The only thing that appears you'll have to do is unset 'CONFIG_SMP'.
My machines didn't
On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
>
> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
Neither 4.8.10, nor 4.8.9 show the bug.
It must be a bug ousid
On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
> I don't understand it, bit please test the attached patch
> with dynamic debugging for cdc-acm and the kernel log level
> at maximum.
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 6895f9e..f03b5db
On Tue, Nov 22, 2016 at 06:50:28PM +0100, Bjørn Mork wrote:
> > iCountryCodeRelDate4 04052004
> > wCountryCode 0x4803
>
> No excuse for crashing of course, but that's one of the sickets
> descriptor sets I've seen today. Who got the bright idea to put the
>
On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote:
> > On kernel 4.8.8 this crashes hard and produces over a serial link:
>
> Huh? That device shouldn't ever enter that code path AFAICS.
> Unless you wouldn't happen to add a dynamic entry for this device,
No idea of what you mean
On Wed, Nov 16, 2016 at 04:07:57PM +0100, Wim Osterholt wrote:
> A bit of patience please. Yesterday I hadn't the modem at hand.
Whell, I lost track of what happens where with which config file..
Confusion about the bug not appearing an too many configs with SMP set
where I'm sure the machin
On Thu, Nov 17, 2016 at 02:57:33AM +0100, Wim Osterholt wrote:
> Now a retry of 4.9-rc5. I take the config of 4.8.8 and accept
> the default for the new options.
> SMP set. No call trace appears.
> For completeness I should also try with SMP unset. That is for tomorrow
> then.
On Wed, Nov 16, 2016 at 01:34:30PM +0100, Oliver Neukum wrote:
>
> This is very odd. We need to know where it crashes. Please try the
> insane debug patch I posted.
A bit of patience please. Yesterday I hadn't the modem at hand.
Groeten, Wim.
On Thu, Nov 17, 2016 at 10:14:34AM +0100, Wim Osterholt wrote:
> > For completeness I should also try with SMP unset. That is for tomorrow
> > then.
>
> With CONFIG_SMP unset nothing goes wrong here either.
> It looks like it has been fixed in 4.9-rc5, but I should also d
On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
> On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:
>
> > Nov 17 15:07:51 localhost kernel: Check point 10
> > Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer
> > dereferenc
On Tue, Nov 15, 2016 at 12:26:00PM +0100, poma wrote:
> > In the process of searching, many options may have changed. The crash/OOPS
> > has now mitigated into just a WARNING with a call trace.
> > (Or it could be a totally different bug?)
> >
> > Tests on other machines with (slightly) different
On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> Hi,
>
> I got one of those devices. However, I don't get a crash.
> Could you please give me instructions on how you trigger it?
That's not too hard, just plug it in. :-)
However you must have set cdc_acm in your kernel, or
On Sat, Jan 07, 2017 at 05:11:38PM +0100, Wim Osterholt wrote:
> On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
>
> L.S.,
> >
> > after appearance of kernel-4.10-rc1 two days ago...
>
> A quickly following release of 4.10-rc2 made sure that lir
On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
L.S.,
>
> after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
> to find a question about lirc_serial in 'make oldconfig':
>
> Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
>
L.S.,
after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
to find a question about lirc_serial in 'make oldconfig':
Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y
I was used to 'lirc_serial:
On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
> I don't understand it, bit please test the attached patch
> with dynamic debugging for cdc-acm and the kernel log level
> at maximum.
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 6895f9e..f03b5db
On Tue, Nov 22, 2016 at 06:50:28PM +0100, Bjørn Mork wrote:
> > iCountryCodeRelDate4 04052004
> > wCountryCode 0x4803
>
> No excuse for crashing of course, but that's one of the sickets
> descriptor sets I've seen today. Who got the bright idea to put the
>
On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote:
> > On kernel 4.8.8 this crashes hard and produces over a serial link:
>
> Huh? That device shouldn't ever enter that code path AFAICS.
> Unless you wouldn't happen to add a dynamic entry for this device,
No idea of what you mean
On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> On Tue, 2016-09-20 at 17:45 +0200, Wim Osterholt wrote:
>
> Anyway, which of its configurations is used?
> Please look up the bConfigurationValue for your device
> in sysfs.
And what might that be?
'locate sysfs
On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> in sysfs.
Google pointed me to /sys/bus/usb/drivers/usb/*
where I find all kinds of 'bConfigurationValue'.
Now is the problem to find which one you could mean.
Under /sys/bus/usb/drivers/usb/7-1 I find
manufacturer which reads
> >Please look up the bConfigurationValue for your device
> >in sysfs.
I didn't explicitly say that this was done under kernel-4.7.4, otherwise
it may have been impossible under 4.8 .
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
>
> OK. Strange. Please do
>
> dmesg -c
>
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> OK. Strange. Please do
>
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
>
> [plug your device in]
>
> and provide the full output of dmesg after
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
>
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
>
> [plug your device in]
>
> and provide the full output of dmesg after that.
That is not
On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
L.S.,
>
> after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
> to find a question about lirc_serial in 'make oldconfig':
>
> Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
>
On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> Hi,
>
> I got one of those devices. However, I don't get a crash.
> Could you please give me instructions on how you trigger it?
That's not too hard, just plug it in. :-)
However you must have set cdc_acm in your kernel, or
, but it says
null pointer dereference at 0246
...
failed while handling devices/pci:00/:00:1d.3/usb7/7-1/7-1:1d etc.
...
udevd .. is taking too long..
Could someone please explain and repair the magic that is happening here?
Thanks in advance, Wim Osterholt.
- w...@djo.tudelft.nl -
On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> >
> > The oops tells things that I didn't all write down, but it says
> > null pointer dereference at 0246
>
> That is the important part. I am sorry, but without the oops
> nobody can help you. Please capture it
Sep 6
On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep 6 19:12:38 localhost kernel: Call Trace:
> > Sep 6 19:12:38 localhost kernel: [] ? 0xc01f4347
>
> Hi,
>
> your stack trace is broken. Did you fail to install the System.map file?
Never needed that for anything the last 20
On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep 6 19:12:38 localhost kernel: Call Trace:
> > Sep 6 19:12:38 localhost kernel: [] ? 0xc01f4347
>
> Hi,
>
> your stack trace is broken. Did you fail to install the System.map file?
Source is available under /usr/src/linux
> your stack trace is broken. Did you fail to install the System.map file?
>
> Regards
> Oliver
>Finally found something.
>CONFIG_DEBUG_INFO was not set.
Doesn't make any difference either.
Compiled cdc_acm in the kernel, not as a module. Doesn't make any
difference, except
On Tue, Sep 20, 2016 at 03:05:14PM +0200, Oliver Neukum wrote:
>
> I cannot replicate it. Could you please provide "lsusb -v"?
>
> Regards
> Oliver
It concerns these type of modems:
http://www.ebay.nl/itm/191933738340
http://www.ebay.nl/itm/121590899044
lsusb:
Bus 002
On Wed, Nov 16, 2016 at 01:34:30PM +0100, Oliver Neukum wrote:
>
> This is very odd. We need to know where it crashes. Please try the
> insane debug patch I posted.
A bit of patience please. Yesterday I hadn't the modem at hand.
Groeten, Wim.
On Wed, Nov 16, 2016 at 04:07:57PM +0100, Wim Osterholt wrote:
> A bit of patience please. Yesterday I hadn't the modem at hand.
Whell, I lost track of what happens where with which config file..
Confusion about the bug not appearing an too many configs with SMP set
where I'm sure the machin
On Thu, Nov 17, 2016 at 02:57:33AM +0100, Wim Osterholt wrote:
> Now a retry of 4.9-rc5. I take the config of 4.8.8 and accept
> the default for the new options.
> SMP set. No call trace appears.
> For completeness I should also try with SMP unset. That is for tomorrow
> then.
On Thu, Nov 17, 2016 at 10:14:34AM +0100, Wim Osterholt wrote:
> > For completeness I should also try with SMP unset. That is for tomorrow
> > then.
>
> With CONFIG_SMP unset nothing goes wrong here either.
> It looks like it has been fixed in 4.9-rc5, but I should also d
On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
> On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:
>
> > Nov 17 15:07:51 localhost kernel: Check point 10
> > Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer
> > dereferenc
On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
>
> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
Neither 4.8.10, nor 4.8.9 show the bug.
It must be a bug ousid
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> It definitely does not crash and is probed and your .config is not
> extremely unusual.
Hmmm.
> ... Something odd is going on.
Whell, yes.
The only thing that appears you'll have to do is unset 'CONFIG_SMP'.
My machines didn't
On Tue, Nov 15, 2016 at 12:26:00PM +0100, poma wrote:
> > In the process of searching, many options may have changed. The crash/OOPS
> > has now mitigated into just a WARNING with a call trace.
> > (Or it could be a totally different bug?)
> >
> > Tests on other machines with (slightly) different
On Sat, Jan 07, 2017 at 05:11:38PM +0100, Wim Osterholt wrote:
> On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
>
> L.S.,
> >
> > after appearance of kernel-4.10-rc1 two days ago...
>
> A quickly following release of 4.10-rc2 made sure that lir
On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
>
> your stack trace is broken. Did you fail to install the System.map file?
>
> Regards
> Oliver
A laptop, more broken than the rest, does not output anything after
inserting. Later on it crashes. No system.map
On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
>
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
>
> [plug your device in]
>
> and provide the full output of dmesg after that.
After some
On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
>
> Very good. This is a valid oops. We can do two things. When I
> decode it, seems to crash in acm_alloc_minor() which does not make
> sense. It is likely that our kernels or compilers are a bit different.
> Could you please call
On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
> this should show you where it crashes. In addition I've attached
> a patch with paranoid debugging. Could you compile and test a kernel
> with it?
>
> Regards
> Oliver
If you mean
echo "module cdc_acm +mpf" >
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: Manufacturer: Conexant
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: SerialNumber: 12345678
With that unique serial number it must be that very device. :-)
> It definitely does
L.S.,
after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
to find a question about lirc_serial in 'make oldconfig':
Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y
I was used to 'lirc_serial:
On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> On Mon, 2016-10-17 at 17:20 +0200, Wim Osterholt wrote:
> > On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> > > Hi,
> > >
> > > I got one of those devices. However, I don't
On Wed, Sep 28, 2016 at 05:23:30PM +0200, Oliver Neukum wrote:
> >
> > HP src # sync
> > HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer
> > dereference at 0249
>
> The last view lines before that please with the debugging level ramped
> up to 9 please.
Recompiled again,
On Wed, Sep 28, 2016 at 07:38:41PM -0400, Sinan Kaya wrote:
>
> Can you try these patches on your machines please?
I applied the included patches on vanilla 4.8-rc8 and my machine booted
fine. (I saw a remark about SCSI interrupts, but I have no SCSI.)
Regards, Wim.
space for ioctl-only open().
>
> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
> modes, while still keeping the original O_NDELAY bug fixed.
>
> Cc: sta...@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt
> Tested-by: Wim Osterholt
> Signed-off-by: Jir
On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote:
>
> Thanks, It was a guess with no proof.
>
> Let's undo the change above and start adding some print statements to collect
> data from your system.
>
> Can you add this to the end of acpi_irq_get_penalty function and then send
> the
On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> On 2016-06-21 18:13, Wim Osterholt wrote:
> >>
> >>pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> >>penalty);
> >>
> >
> >
On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
> >
> > Sure, let me get a patch for you.
>
> Here it is
http://webserver.djo.tudelft.nl/dmesg460+printpatch2
> I am trying to find a system with similar characteristics for debug
All from the same laptop, Dell Inspiron 4100.
The
L.S.
up to vanilla kernel-4.6.2 sound was working fine.
Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc.
There appears to be a bug in the Intel sound driver and/or ACPI driver.
Dmesg shows interesting lines like:
[ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
> Can you try the following and see if it makes any difference?
>
>
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
> int penalty = 0;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - penalty +=
On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote:
>
> Can you give it a try?
Whell, I tried to no avail.
Wether it is on 4.6 or 4.7, with or without your previous patch,
I keep getting rejected hunks.
For example, here the line to be deleted is nowhere to be found:
> diff --git
On Sat, Jun 25, 2016 at 04:51:03AM -0400, ok...@codeaurora.org wrote:
> On 2016-06-24 21:39, Wim Osterholt wrote:
>
> Please apply the patches on top of clean 4.7-rc4 tree and apply them in
> order with
>
> git am 0001...
> git am 0002...
It doesn't work that way.
Beginn
On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote:
> > However, an earlier try on my Inspiron 510m did not work.
> > I'll do a clean retry later today, just to make sure.
>
>
> Ok, let me know. I can post a clean patch series. I was trying to get
> you something to test
t is quite similar to the one from kernel-4.6 .
Tested-by: Wim Osterholt.
On Wed, Jun 15, 2016 at 04:13:53PM +0200, Jiri Kosina wrote:
>
> Wim, could you please test whether the patch below, applied on top of
> vanilla kernel (i.e. drop the revert), everything you are using still
> works as expected?
>
Applied on kernel-4.7-rc3 it looks like it's working. (Strace
On my first message I stated:
It looks to me that the code in floppy.c is quite old; no changes here.
So the bug is elsewhere in the kernel.
That was because the changelog at the beginning of floppy.c ended in 2003.
Wouln't it be wise to keep these items updated?
Groeten, Wim.
-
On Mon, Jun 13, 2016 at 02:15:15PM +0200, Jiri Kosina wrote:
> > up to vanilla kernel 4.4.13 floppy functionality performs like it should.
> > (On an x86 PC that is. With a 1.44MB diskette drive.)
> > >From kernel 4.5* and up it changed to barely usable.
> >
> > After a virgin start (cold or
On Wed, Jun 15, 2016 at 09:09:13AM +0200, Jiri Kosina wrote:
> > Surprising or not, the thusly compiled kernel ran fine and I could
> > handle floppies like before! (open(/dev/fd0,O_ACCMODE) succeeds.)
>
> Thanks for testing.
>
> Now next question -- what do you actually want to achieve with
ere in the kernel.
Could someone please explain and repair the magic that is happening here?
Thanks in advance, Wim Osterholt.
- w...@djo.tudelft.nl -
On Sat, Jun 11, 2016 at 02:15:01PM +0100, One Thousand Gnomes wrote:
> > open(/dev/fd0, O_ACCMODE) = -1
> If you do
>
> touch foo
>
> then compile and run the following program does it error on the newer
> kernel ?
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> if
100 matches
Mail list logo