Re: What is "#define alloc_ieee80211 alloc_ieee80211_rsl"?
On Tue, Oct 09, 2018 at 08:07:08PM +0100, John Whitmore wrote: > Sorry I know what a #define is doing, but in this case I've no idea > why it's used and what it's trying to achieve. > > This is from the rtl8192u driver in staging, where the alloc function > (alloc_ieee80211) which is called by the probe function > (rtl8192_usb_probe). So that's all good but a quick grep through the > code and in the file drivers/staging/rtl8192u/ieee80211/ieee80211.h > there's a line which defines that function as another function '_rsl' > which don't exist anywhere in Kernel. > > #define alloc_ieee80211 alloc_ieee80211_rsl > > So what am I missing or why are a number of functions being redefined > as another name, which doesn't exist? > > I'm tempted to remove any that don't exist but I should really find > out what it is the lines are doing. I should have held off for a few minutes. I removed all the '_rsl' defines from the code and the module re-builds so I think I'll just submit a patch. Unless somebody has a good reason not to. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
What is "#define alloc_ieee80211 alloc_ieee80211_rsl"?
Sorry I know what a #define is doing, but in this case I've no idea why it's used and what it's trying to achieve. This is from the rtl8192u driver in staging, where the alloc function (alloc_ieee80211) which is called by the probe function (rtl8192_usb_probe). So that's all good but a quick grep through the code and in the file drivers/staging/rtl8192u/ieee80211/ieee80211.h there's a line which defines that function as another function '_rsl' which don't exist anywhere in Kernel. #define alloc_ieee80211 alloc_ieee80211_rsl So what am I missing or why are a number of functions being redefined as another name, which doesn't exist? I'm tempted to remove any that don't exist but I should really find out what it is the lines are doing. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
staging:rtl8192u: Possible memory leak?
I've been going through the rtl8192u driver in drivers/staging trying to get a better understanding of the code. It's possibly not the text book network driver but it seemed as good a place to start as any. So I'm looking at the allocation function in ieee80211_module.c: struct net_device *alloc_ieee80211(int sizeof_priv) And can't figure out how there's not a possible memory leak. Either there is a memory leak or I'm misunderstanding the code. Possibly the latter is more likely but I thought I'd ask for clarification. The way I read the function the net_device is allocated with a call to alloc_etherdev() and if that call fails the code does a 'goto failed'. If the allocation of the net_device succeeds the funcion ieee80211_networks_allocate() is called, which allocates an array of 128 structures. If that allocation fails then again 'goto failed' That's all fine so far but on line 160 a third allocation is attempted and again 'goto failed' but ieee80211_network_free(ieee) is never called to clean up from the call to ieee80211_networks_allocate() This might all be a mute point as I seem to remember someone saying that memory allocation never fails in Linux and this can only happen if the first two allocations work and the third fails. Still thought I'd ask and possibly learn why I'm wrong, on so many levels ;) jwhitmore ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Merge Window closed, submitting patches?
On Sun, Aug 26, 2018 at 03:47:32PM +0100, Justin Skists wrote: > > > On 26 August 2018 at 15:36 John Whitmore wrote: > > > > > > My question is about what to do during the closed window? I don't think I > > should submit patches as I assume I'll create a backlog for the maintainer > > who'll possibly be flooded when the window re-opens. Similarly I could > > create > > patches but not send them until the window re-opens, but again I'll just be > > creating a backlog. > > Just keep going. The maintainers will keep a queue of patches and then try to > apply them in order when the merge window -rc1 is released for the next one. > > Worse cases would be that the patches will no longer apply (in which case, a > V2 will be needed) or, if you haven't heard anything for a while after the > -rc1, then a patch RESEND should do the trick. > > Hope that helps, > Justin. Thank you, yes that helps! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Merge Window closed, submitting patches?
Recently got into the habit of making very simple coding style changes in staging. It's basic, but it is a gentle introduction to the process involved in submitting patches to the kernel. So the merge window is now closed and I have submitted a few patch sets, the first not knowing that the window was closed, and the second wrongly thinking that the window had reopened. My question is about what to do during the closed window? I don't think I should submit patches as I assume I'll create a backlog for the maintainer who'll possibly be flooded when the window re-opens. Similarly I could create patches but not send them until the window re-opens, but again I'll just be creating a backlog. So I guess I should just be patient and find something else to do for a while, but thought I'd ask. I have tried to find the answer to this but haven't found one. jwhitmore ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Use of enums, why?
On Wed, Jul 11, 2018 at 11:40:18AM +0200, Greg KH wrote:
> On Wed, Jul 11, 2018 at 10:30:28AM +0100, John Whitmore wrote:
> > I only learning the ropes, and might have missed the memo on the use of
> > enums
> > so forgive me. I have looked at
> > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#macros-enums-and-rtl
> > but that didn't answer my question.
> >
> > I'm doing a clean up of staging:rtl8192u: clearing out checkpatch errors and
> > triming out data structures which aren't used in the code. So I came across
> > a
> > typedef of an enumerated type in the file:
> >
> > drivers/staging/rtl8192u/r8192U.h
> >
> > typedef enum rf_optype {
> >RF_OP_By_SW_3wire = 0,
> >RF_OP_By_FW,
> >RF_OP_MAX
> > } rf_op_type;
>
> To fix this up for checkpatch, it should just look like:
>
> enum rf_optype {
> RF_OP_By_SW_3wire = 0,
> RF_OP_By_FW,
> RF_OP_MAX
> };
>
> > A quick grep for this type in drivers/staging/rtl8192u directory shows that
> > the type is never used outside that header definition. So I can remove it?
>
> As you found out, no :)
>
> > Well no you can't because the values defined in the enum are used.
> >
> > In drivers/staging/rtl8192u/r8192U_core.c for example:
> > priv->Rf_Mode = RF_OP_By_SW_3wire;
> >
> > that element priv->Rf_Mode is defined in the structure
> >
> > typedef struct r8192_priv {
> > ...
> > u8 Rf_Mode; /* For Firmware RF -R/W switch */
>
> Ah, that should be:
> enum rf_optype RF_Mode;
> right?
>
> > ...
> > }
> >
> >
> > So now to the question, as I understand it the compiler will use an int type
> > for the enumerated type. The data structure r8192_priv doesn't use this int
> > type
> > because the programmer knows that a u8 will do to hold the 3 possible values
> > defined by the enumerated type.
>
> Or someone messed up and didn't realize that is what was holding those
> values :)
>
> > So you're saving a few bytes in a data structure, which I'm happy about, but
> > the point of enumerated types is, as I understand it, so that the compiler
> > can
> > do some checking to ensure a value is not assigned in error.
>
> You are correct.
>
> > Since the enum isn't being used, there is no compiler type checking,
> > so why use an enumerated type? Might as well have used three #define
> > values.
>
> That too would work, but you loose the typechecking.
>
> > The obvious thing to do is leave well enough alone. But I had to ask what is
> > the correct implementation? Use the enum in the data structure, instead of
> > u8? Or just #define a few constants?
> >
> > #define RF_OP_By_SW_3wire1
> > #define RF_OP_By_FW 2
> > #define RF_OP_MAX3
> >
> > Given the space saving of u8 over int I'd probably go with the #define.
> > Guess
> > it depends on how many of those data structures are being declared.
>
> I'd stick to the define, UNLESS this structure is coming from/to the
> hardware directly. Then you need to use u8. So look and see if that is
> what is happening here or not. If it's just a "normal" structure in
> memory, then use an enum to keep the type safety.
>
> hope this helps,
>
> greg k-h
Yes that clears that up.
Thanks a million
John
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Use of enums, why?
I only learning the ropes, and might have missed the memo on the use of enums
so forgive me. I have looked at
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#macros-enums-and-rtl
but that didn't answer my question.
I'm doing a clean up of staging:rtl8192u: clearing out checkpatch errors and
triming out data structures which aren't used in the code. So I came across a
typedef of an enumerated type in the file:
drivers/staging/rtl8192u/r8192U.h
typedef enum rf_optype {
RF_OP_By_SW_3wire = 0,
RF_OP_By_FW,
RF_OP_MAX
} rf_op_type;
A quick grep for this type in drivers/staging/rtl8192u directory shows that
the type is never used outside that header definition. So I can remove it?
Well no you can't because the values defined in the enum are used.
In drivers/staging/rtl8192u/r8192U_core.c for example:
priv->Rf_Mode = RF_OP_By_SW_3wire;
that element priv->Rf_Mode is defined in the structure
typedef struct r8192_priv {
...
u8 Rf_Mode; /* For Firmware RF -R/W switch */
...
}
So now to the question, as I understand it the compiler will use an int type
for the enumerated type. The data structure r8192_priv doesn't use this int type
because the programmer knows that a u8 will do to hold the 3 possible values
defined by the enumerated type.
So you're saving a few bytes in a data structure, which I'm happy about, but
the point of enumerated types is, as I understand it, so that the compiler can
do some checking to ensure a value is not assigned in error. Since the enum
isn't being used, there is no compiler type checking, so why use an enumerated
type?
Might as well have used three #define values.
The obvious thing to do is leave well enough alone. But I had to ask what is
the correct implementation? Use the enum in the data structure, instead of
u8? Or just #define a few constants?
#define RF_OP_By_SW_3wire1
#define RF_OP_By_FW 2
#define RF_OP_MAX3
Given the space saving of u8 over int I'd probably go with the #define. Guess
it depends on how many of those data structures are being declared.
thanks for any thoughts or clarification
John
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
staging: rtl8192u: Header file organisation and cleanup?
Hello all,
I've had a few goes at code style clean up of the file
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c Unfortunately the low
hanging fruit has been cleared, and a lot of the checkpatch errors are down to
line length or to CamelCase. So I decided I'd have a look at camel case.
I had a look at a local variable in the first function in the file:
void HTUpdateDefaultSetting(struct ieee80211_device *ieee)
{
PRT_HIGH_THROUGHPUT pHTInfo = ieee->pHTInfo;
Now that type PRT_HIGH_THROUGHPUT is declared in the header file
#include "rtl819x_HT.h"
which is included at the top of the C file. As is another header file:
#include "ieee80211.h"
These header files are the reason for this question. The ieee80211.h file also
includes the rtl819x_HT.h file so the file is included twice, but protected by
a #ifndef at the top of the file.
So my first question would be if you were trimming the number of includes of
that header file would the include in the C File be removed, or alternatively
the include in ieee80211.h be removed?
The second question is to do with the name of those files. I'm wroking in
staging/rtl8192u but that header file name is mirrored in staging/rtl8192e
$ find -name rtl819x_HT.h -print
./drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
./drivers/staging/rtl8192e/rtl819x_HT.h
$ find . -name "*.[ch]" -exec grep "rtl819x_HT.h" {} /dev/null \;
./drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c:#include "rtl819x_HT.h"
./drivers/staging/rtl8192u/ieee80211/ieee80211.h:#include "rtl819x_HT.h"
./drivers/staging/rtl8192e/rtl819x_HTProc.c:#include "rtl819x_HT.h"
./drivers/staging/rtl8192e/rtllib.h:#include "rtl819x_HT.h"
I'm wondering given that there are two different files they should be renamed
to rtl819u_HT.h and rtl819e_HT.h?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to debug video in the Linux Kernel?
On Mon, Jun 11, 2018 at 02:12:55PM +0200, Ricardo Ribalda Delgado wrote: > Hi John > On Thu, Jun 7, 2018 at 2:05 PM John Whitmore wrote: > > > > > Maybe that problem is not in the kernel at all but vlc does display videos > > correctly. I've also been through all the vlc settings and can't find > > anything > > that makes a different. > > Have you tried using qv4l2 from Hans Vekuil: > > https://events.static.linuxfound.org/sites/events/files/slides/v4l2-testing_0.pdf > > as a test application? Thanks a million for that link, I'd not found it in my searches but reading through and going to try it out to see if I can get to the bottom of the problem thanks again ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to debug video in the Linux Kernel?
Hello all, I'm running OpenSUSE Tumbleweed so I'm just using their stock 4.16.12-1-default kernel at the moment. I'm not sure what has changed recently in their system but I'm having problems with video devices. This is a laptop with a single built in USB Camera, but for some reason two devices are created for that device: $ ls /dev/vid* /dev/video0 /dev/video1 I don't really use that camera but I then have a HDMI to USB capture device which I do use. When that's plugged in again I get two devices created, which I could live with, but the bigger problem is that the video being captured is not the full resolution of the camera connected. I'm displaying the camera's video with vlc and it's only displaying about 1/2 of the screen and totally distorted. The capture device is a MAGEWELL: [ 9033.836808] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd [ 9033.857976] usb 2-4: New USB device found, idVendor=2935, idProduct=0001 [ 9033.857983] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 9033.857988] usb 2-4: Product: XI100DUSB-HDMI [ 9033.857991] usb 2-4: Manufacturer: Magewell [ 9033.857995] usb 2-4: SerialNumber: A201161110153 [ 9033.859190] uvcvideo: Found UVC 1.00 device XI100DUSB-HDMI (2935:0001) [ 9033.860466] input: XI100DUSB-HDMI: XI100DUSB-HDMI as /devices/pci:00/:00:14.0/usb2/2-4/2-4:1.0/input/input26 [ 9033.862538] hid-generic 0003:2935:0001.0005: hiddev97,hidraw2: USB HID v1.01 Device [Magewell XI100DUSB-HDMI] on usb-:00:14.0-4/input4 [ 9034.432710] usbcore: registered new interface driver snd-usb-audio $ lsusb Bus 002 Device 002: ID 2935:0001 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 0951:1643 Kingston Technology DataTraveler G3 Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 002: ID 06cb:0078 Synaptics, Inc. Bus 001 Device 004: ID 8087:0aa7 Intel Corp. Bus 001 Device 003: ID 04f2:b5a7 Chicony Electronics Co., Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub *MOUSE* But now four video devices show up in /dev: $ ls /dev/vid* /dev/video0 /dev/video1 /dev/video2 /dev/video3 I've tried plugging both a digital camera into the HDMI capture device and the HDMI output of the laptop but in both cases I'm getting the same result a fraction of the screen and distorted. I've taken a screenshot and uploaded it so it might better describe what I'm seeing. So up above in this email I've added the text "*MOUSE*" my mouse if positioned on that word in the screen shot, but it doesn't come out in the screen capture as it didn't capture my mouse pointer. So in the screen capture you can see where my mouse is positioned over that text about half way down the screen of the laptop. If you then look at the VLC window which is displaying this captured video you can see the mouse pointer is right at the bottom of the captured video. https://pasteboard.co/HoMHNqa.png Maybe that problem is not in the kernel at all but vlc does display videos correctly. I've also been through all the vlc settings and can't find anything that makes a different. So given all that I'm wondering how I get to the problem with this? Searching for the words linux and video hasn't given me any insight as to how to locate the source of the problem. I'll revert to OpenSUSE Leap and see if I can't get back to having this working. Still I'd love to know how to resolve this issue, or at least shed some light on the source of the problem. John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why do some config options return limited info from a search?
On Sun, Mar 18, 2018 at 08:49:52PM -0400, valdis.kletni...@vt.edu wrote: > On Mon, 19 Mar 2018 00:08:10 -0000, John Whitmore said: > > > Sometimes however you get a module which don't give this information. Is > > this > > intentional, signify something, or just an oversight for that config option? > > For example SND_HDA_CORE: > > > Symbol: SND_HDA_CORE [=m] > > Type : tristate > > Defined at sound/hda/Kconfig:1 > > Depends on: SOUND [=y] && !UML && SND [=y] > > Selects: REGMAP [=y] > > Selected by: > > - SND_HDA_EXT_CORE [=m] && SOUND [=y] && !UML && SND [=y] > > - SND_HDA [=m] && SOUND [=y] && !UML && SND [=y] > > Some internal symbols don't have any visible menu-selects, because they are > intended to be turned on only via other things doing 'SELECT'. After all, > SND_HDA_CORE has little to no reason to be enabled unless your kernel build > config asks for SND_HDA or SND_HDA_EXT_CORE (and *that* symbol is 'm', which > is > why SND_HDA_CORE is also ''m'. Switching EXT_CORE to 'y' will then > auto-switch > this one to 'y' as well). > Perfectly logical and simple. Thanks for your answer that now all makes sense. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Why do some config options return limited info from a search?
I'm trying to build the required options for my Laptop into the kernel, so not modules. When you search, in make menuconfig, for a config option you usually get very useful info about where it is, in the menus, and what its prompt is. This makes them easier to find. Sometimes however you get a module which don't give this information. Is this intentional, signify something, or just an oversight for that config option? For example SND_HDA_CORE: Symbol: SND_HDA_CORE [=m] Type : tristate Defined at sound/hda/Kconfig:1 Depends on: SOUND [=y] && !UML && SND [=y] Selects: REGMAP [=y] Selected by: - SND_HDA_EXT_CORE [=m] && SOUND [=y] && !UML && SND [=y] - SND_HDA [=m] && SOUND [=y] && !UML && SND [=y] ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem installing kernel due to virtualbox?
On Wed, Mar 14, 2018 at 08:58:05PM +, Alex Arvelaez wrote: > > I've been AWOL working on other things for an age, so just getting back up > > to speed and building a kernel. Everything built successfully but when I > > try to install the kernel (64bit laptop) it fails due to a virtualbox error. > > > > ERROR (dkms apport): kernel package linux-headers-4.16.0-rc5 is not > > supported > > Error! Bad return status for module build on kernel: 4.16.0-rc5 (x86_64) > > Consult /var/lib/dkms/virtualbox/5.0.40/build/make.log for more > > information. > > > > I've had a look at that log file but it doesn't say a whole lot more: > > > > ...linux/scripts/Makefile.build:583: recipe for target > > '/var/lib/dkms/virtualbox/5.0.40/build/vboxdrv' failed > > make[5]: *** [/var/lib/dkms/virtualbox/5.0.40/build/vboxdrv] Error 2 > > Makefile:1552: recipe for target > > '_module_/var/lib/dkms/virtualbox/5.0.40/build' failed > > make[4]: *** [_module_/var/lib/dkms/virtualbox/5.0.40/build] Error 2 > > Makefile:24: recipe for target '__sub-make' failed > > make[3]: *** [__sub-make] Error 2 > > > > An Internet search did throw up a few pages about a virtualbox error [1] > > but I'm not sure the relevance to installing a Linux Kernel. Unless 'sudo > > make install' is running an Ubuntu script which tries to mess with virtual > > box. I have removed virtualbox from this machine and tried again but I've > > still got the same error message in the install process. Maybe I have to > > reboot after removing virtualbox but it still seems a bit tightly coupled? > > you probably want to remove virtualbox-dkms. Your system is trying to > recompile the vbox driver for your newly compiled kernel and failing because > it's not supported. > > I'm not sure what triggers dkms specifically so I'm not sure how to avoid it. > > Regards, > > Alex Thanks a million Alex, as you suggested removing that package got me up and running. John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Problem installing kernel due to virtualbox?
I've been AWOL working on other things for an age, so just getting back up to speed and building a kernel. Everything built successfully but when I try to install the kernel (64bit laptop) it fails due to a virtualbox error. ERROR (dkms apport): kernel package linux-headers-4.16.0-rc5 is not supported Error! Bad return status for module build on kernel: 4.16.0-rc5 (x86_64) Consult /var/lib/dkms/virtualbox/5.0.40/build/make.log for more information. I've had a look at that log file but it doesn't say a whole lot more: ...linux/scripts/Makefile.build:583: recipe for target '/var/lib/dkms/virtualbox/5.0.40/build/vboxdrv' failed make[5]: *** [/var/lib/dkms/virtualbox/5.0.40/build/vboxdrv] Error 2 Makefile:1552: recipe for target '_module_/var/lib/dkms/virtualbox/5.0.40/build' failed make[4]: *** [_module_/var/lib/dkms/virtualbox/5.0.40/build] Error 2 Makefile:24: recipe for target '__sub-make' failed make[3]: *** [__sub-make] Error 2 An Internet search did throw up a few pages about a virtualbox error [1] but I'm not sure the relevance to installing a Linux Kernel. Unless 'sudo make install' is running an Ubuntu script which tries to mess with virtual box. I have removed virtualbox from this machine and tried again but I've still got the same error message in the install process. Maybe I have to reboot after removing virtualbox but it still seems a bit tightly coupled? [1] https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1729568 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Found a problem so what next?
On Mon, Jan 18, 2016 at 11:36:25PM -0800, Greg KH wrote: > On Mon, Jan 18, 2016 at 05:34:32PM +0000, John Whitmore wrote: > > I built and installed v4.4 on my laptop but Suspend no longer worked so I > > set > > about doing a git bisect to find the source of the problem. I've never had > > cause to use bisect before so if nothing else I'll have learned something. > > > > Anyhow got to an end point in git bisect of: > > > > john@bamboo:> git bisect bad > > Bisecting: 0 revisions left to test after this (roughly 0 steps) > > [b8b2c7d845d57f7a4b9f1f941f24728165e27626] base/platform: assert that > > dev_pm_domain callbacks are called unconditionally > > > > I was actually chuffed I got that far and it took a while as I was doing a > > "make mrproper" each time. I sort of assumed that I could just bisect and > > do a > > make, which would work out what it had to recompile, but then thought maybe > > that was a bit of an assumption. Be a shame to do all that work and find out > > you had to clean up a bit between builds. > > You don't have to, a simple 'make oldconfig' and 'make' should do just > fine. > > > I'm sure that this problem has been found and a patch submitted by now as it > > seems to have been from months ago. But assuming neither had occured and > > this > > was a new discovery how do you check for a reported bug? Do you search > > mailing > > list for that commit number, or a part of that commit number? > > Yes, this bug has been found, and a fix was submitted, I just haven't > taken it yet, sorry. I will do so after 4.5-rc1 is out. If you search > the linux-kernel mailing list for: > Subject: [PATCH] base/platform: Fix platform drivers with no probe > callback (ex alarmtimer) > > you can find the fix. > > Sorry you hit this, I'll get it merged soon. > Hey not at all, I'm glad I did hit the problem. I'm re-reading LDD for probably the third time and soaking up a little bit more, before I start work on a USB driver. I was glad of the distraction and happy to try see if I could find the source of the problem. If I wasn't busy I might even try and see if I could debug it and get my own fix, just for the exercise and learning. Who knows maybe it'll be a slow weekend ;-) > greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Found a problem so what next?
On Tue, Jan 19, 2016 at 10:50:32AM +0100, Bjørn Mork wrote: > John Whitmore <arig...@gmail.com> writes: > > I'm sure that this problem has been found and a patch submitted by now as it > > seems to have been from months ago. But assuming neither had occured and > > this > > was a new discovery how do you check for a reported bug? Do you search > > mailing > > list for that commit number, or a part of that commit number? > > I cannot tell you what the best practice is, but at least that's what I > do. > > Googling for a fix is usually pretty accurate once the problematic > commit has been found. Both the short title and the 12 digit commit ID > should work, because they are included in the "Fixes" tag of the fix. > Thanks a million I just did a search for the 12 digit commit ID and found the discussion on the mailing list. Most of it over my head but thanks for the information. > Unfortunately Googling isn't as accurate before you know the buggy > commit. In an ideal world, you should be able to find the fix based on > the symptoms described in the commit message. But this doesn't work well > for symptoms which occur frequently and with varying causes. "suspend > failing" is definitely one of those... > > And yes, it is common to discover what you did: The bug is already found > and fixed, but the fix hasn't propagated yet. That can be a bit > demotivating until you realize the beauty of a system where someone else > already fixed your problem and documented the fix in a public "bug > database" :) > > > Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Found a problem so what next?
I built and installed v4.4 on my laptop but Suspend no longer worked so I set about doing a git bisect to find the source of the problem. I've never had cause to use bisect before so if nothing else I'll have learned something. Anyhow got to an end point in git bisect of: john@bamboo:> git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [b8b2c7d845d57f7a4b9f1f941f24728165e27626] base/platform: assert that dev_pm_domain callbacks are called unconditionally I was actually chuffed I got that far and it took a while as I was doing a "make mrproper" each time. I sort of assumed that I could just bisect and do a make, which would work out what it had to recompile, but then thought maybe that was a bit of an assumption. Be a shame to do all that work and find out you had to clean up a bit between builds. I'm sure that this problem has been found and a patch submitted by now as it seems to have been from months ago. But assuming neither had occured and this was a new discovery how do you check for a reported bug? Do you search mailing list for that commit number, or a part of that commit number? I read BUG-HUNTING in the documentation and it does mention: "Before you submit a bug report read REPORTING-BUGS." but can't see that document and it's not a section of BUG_HUNTING document. So what would the next step be? I'm sure fixing it would be one posibility but I've never looked at power management code so I'm not the person that should be let lose in there ;-) I had a look in journalctl but nothing in there suggests what the actual error is. I'll have a look at the log files some more and see if I can't get some sort of clue which would provide more info. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Strange warnings out of checkpatch
I'm using the MCP2515 driver chip on some work I'm doing. Out of curiosity I ran checkpatch.pl on the C file and don't understand the output. A search sort of seems to suggest that it is a problem with the checkpatch utility itself. http://www.serverphorums.com/read.php?12,1264313 I'd like to understand what is either wrong with code or chcekpatch $ scripts/checkpatch.pl drivers/net/can/spi/mcp251x.c WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) #727: static void mcp251x_error_skb(struct net_device *net, int can_id, int data1) ERROR: Does not appear to be a unified-diff format patch total: 1 errors, 1 warnings, 0 lines checked drivers/net/can/spi/mcp251x.c has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Building which kernel?
I've a question regarding the building of the linux kernel, more specifically which kernel to build. I've previously built the kernel for an 86 arch but this time I want to build for the RaspberryPi. I can easily get the current version of the installed kernel with the uname -a command but that doesn't tell me the git repo where the kernel originated. I'd imagine that it's from the RPi git repo, but that adds another level of confusion as that git repo doesn't have any tags at all. So even given the version number from uname how to check out a suitable version of the kernel. I could take the latest from the RPi repo and use make oldconfig but I wonder how far, in kernel versions, I can jump and not affect the installed libs and utilities which have been built against another version of the kernel? I've read various documentation on building the linux kernel but that's never really mentioned, mainly I guess as you're building for the x86 Arch. But even there can you jump major versions of kernel without effecting other installed SW in the system? John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Building which kernel?
On Sun, Jun 14, 2015 at 08:27:03AM -0700, Greg KH wrote: On Sun, Jun 14, 2015 at 02:11:33PM +0100, John Whitmore wrote: I've a question regarding the building of the linux kernel, more specifically which kernel to build. Always the latest version, why would you want to build an old one? I've previously built the kernel for an 86 arch but this time I want to build for the RaspberryPi. I can easily get the current version of the installed kernel with the uname -a command but that doesn't tell me the git repo where the kernel originated. I'd imagine that it's from the RPi git repo, but that adds another level of confusion as that git repo doesn't have any tags at all. So even given the version number from uname how to check out a suitable version of the kernel. If you are using hardware that is not completly supported in the main kernel.org repo, like many embedded devices like the RPi, I suggest using the source repo that the project provides instead. I could take the latest from the RPi repo and use make oldconfig but I wonder how far, in kernel versions, I can jump and not affect the installed libs and utilities which have been built against another version of the kernel? You should always be able to use a new kernel on old userspace with no problems. Going backwards is not supported (old kernel on new userspace.) hope this helps, greg k-h Yes that clears up versions, thanks a milion. John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem with SPI RTC DS3234 on RaspberryPi 2
On Sat, Apr 11, 2015 at 09:50:25AM -0700, Henry Hallam wrote: On Sat, Apr 11, 2015 at 6:25 AM, John Whitmore arig...@gmail.com wrote: Original RPi kenel - 3.15.5 RPi-2 kernel - 3.18.8 Maybe try the new kernel version on the old board, to eliminate that variable? Henry I've never been able to boot the 3.18.8 kernel in the RPi (original) it hangs in the boot. It don't seem to be as simple as taking the 3.15.5 config file and make oldconfig. Whilst that does build a kernel which attempts to boot it hangs during the boot process. Possibly due to the change to device trees. Can't seem to find anything on 3.18.8 for original RPi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Problem with SPI RTC DS3234 on RaspberryPi 2
I've had a problem for weeks with a development board I have used in the past on the Original RaspberryPi. The expansion board has two spi devices connected, a CAN Bus controller (MCP2515) and a Real Time Clock chip DS3234. On the old RPi everything works great with two devices in: /sys/bus/spi/devices pi@can-rtc:~$ cat /sys/bus/spi/devices/spi0.0/modalias spi:mcp2515 pi@can-rtc:~$ cat /sys/bus/spi/devices/spi0.1/modalias spi:ds3234 This output is exactly the same on the RPi-2 but the RPi-2 finds the RTC time invalid: sudo hwclock -r hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond. The CAN Bus Controller does work on both versions of the RPi, it's just the RTC that has a problem. If connect up the Ethernet interface to get the correct time, from the network, I can write it to the device with hwclock -w. Then remove the expansion board and power it up on the original RPi and it's got the correct time which is sets as the system time. If I now remove it from the original RPi and connect to RPi-2 it can't read a valid time. but it all seems the same. cat /sys/bus/spi/devices/spi0.1/rtc/rtc0/name ds3234 In both cases I've compiled the ds3234 and mcp2515 drivers into the kernel. In the original RPi the board file is edited to add the two devices but in the RPi-2 a hardware overlay file is added. Like I say everything appears to be exactly the same in both cases. Just the result is totally different. Can anybody explain why there should be a difference? The GPIO headers in both versions of the RPi are the same for the first set of pins. Original RPi kenel - 3.15.5 RPi-2 kernel - 3.18.8 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Recent Kernels failing to boot?
I'm not even sure that this is the correct home for this question but sure it's worth a punt. I'm running OpenSUSE on a netbook and use it to compile and install the latest kernel from Linus's git repo. This has always been a simple operation pulling the latest, updating the config file, make and install. A few versions ago I hit a snag in that once installed the new kernel would show up in the grub2 menu but once selected for boot the machine would just go to a blank screen and hang. I'd have to do a hard reset. I can't be specific on which version this started happening on as the problem is intermittent. It seems to be a race condition sometimes a kernel will boot and sometimes it won't. I thought I could investigate this issue but I can't find any debug info for this problem at all. grub2 is happy as it's handed control over to the kernel but there's no evidence of any kernel activity in the logs at all for the requested boot. So the reason for this post is to ask if anybody could suggest how to debug this issue. I think it came in about 3.14 but like I say it's intermittent. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
