Re: staging: wilc1000: kernel Oops while opening the device
On Mon, Sep 26, 2016 at 05:17:37AM +, aditya.shan...@microchip.com wrote: > On Friday 23 September 2016 08:37 PM, Greg KH wrote: > > On Fri, Sep 23, 2016 at 01:17:08PM +, aditya.shan...@microchip.com > > wrote: > >> On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote: > >>>> -Original Message- > >>>> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > >>>> Sent: Monday, September 19, 2016 7:12 PM > >>>> To: Nicolas Ferre > >>>> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh > >>>> Krishna - I00112; lui...@osg.samsung.com > >>>> Subject: Re: staging: wilc1000: kernel Oops while opening the device > >>>> > >>>> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote: > >>>>> Hi all, > >>>>> > >>>>> While using the wilc1000 driver with latest 4.8-rc7, I have > >>>>> difficulties to open the device and actually use it as I have this > >>>>> kernel Oops right after the loading of the firmware > >>>>> (wilc1003_firmware.bin). > >>>>> > >>>>> If I revert back the driver to its > >>>>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did > >>>>> this because I tend to think that it might be related to the latest > >>>>> move on this driver to "completion" or "work queues". > >>>>> It seems to be a regression from 4.7. > >>>> > >>>> Ick, not good at all. > >>>> > >>>> Any chance you can run 'git bisect' to see if you can find the offending > >>>> patch? > >>>> > >>>> I thought the maintainers were testing this driver over time :( > >>> > >>>> thanks, > >>>> > >>>> greg k-h > >>> > >>> Ick indeed. Maintainers are on it full time. Thank you very much for the > >>> flag. While I am only reporting activity, hope to have results soon. > >>> Regards, > >>> ganesh k > >>> > >> Hi All, > >> > >> bisecting changes on the wilc1000 host driver, I find that this problem > >> seems to occur after the below change. > >> As of now, I only know the where and not the why. So I will continue to > >> figure out why this happens. > >> > >> commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a > >> Author: Binoy Jayan > >> Date: Thu Jun 23 11:11:51 2016 +0530 > >> > >> staging: wilc1000: Replace kthread with workqueue for host interface > >> > >> Deconstruct the kthread / message_queue logic, replacing it with > >> create_singlethread_workqueue() / queue_work() setup, by adding a > >> 'struct work_struct' to 'struct host_if_msg'. The current kthread > >> hostIFthread() is converted to a work queue helper with the name > >> 'host_if_work'. > > > > So if you revert this, it works? > > > > If so, let us know and I will gladly revert it, as breaking things is > > not ok. > > > > thanks, > > > > greg k-h > > > Unfortunately no. We will have to revert this commit and the one submitted > after this. > The commit a5c84b2 after 2518ac5 is heavily reliant on its parent 2518ac5. > > Note that reverting 2518ac5 throws up a couple of minor merge conflicts which > can be > resolved by dropping changes in HEAD and retaining the parent commit of > 2518ac5. > With this, the crash is not seen anymore. Can you send me a patch, or series of patches, that does all of this so I know I get it correct? thanks, greg k-h
Re: staging: wilc1000: kernel Oops while opening the device
On Friday 23 September 2016 08:37 PM, Greg KH wrote: > On Fri, Sep 23, 2016 at 01:17:08PM +, aditya.shan...@microchip.com wrote: >> On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote: >>>> -Original Message- >>>> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >>>> Sent: Monday, September 19, 2016 7:12 PM >>>> To: Nicolas Ferre >>>> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh >>>> Krishna - I00112; lui...@osg.samsung.com >>>> Subject: Re: staging: wilc1000: kernel Oops while opening the device >>>> >>>> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote: >>>>> Hi all, >>>>> >>>>> While using the wilc1000 driver with latest 4.8-rc7, I have >>>>> difficulties to open the device and actually use it as I have this >>>>> kernel Oops right after the loading of the firmware >>>>> (wilc1003_firmware.bin). >>>>> >>>>> If I revert back the driver to its >>>>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did >>>>> this because I tend to think that it might be related to the latest move >>>>> on this driver to "completion" or "work queues". >>>>> It seems to be a regression from 4.7. >>>> >>>> Ick, not good at all. >>>> >>>> Any chance you can run 'git bisect' to see if you can find the offending >>>> patch? >>>> >>>> I thought the maintainers were testing this driver over time :( >>> >>>> thanks, >>>> >>>> greg k-h >>> >>> Ick indeed. Maintainers are on it full time. Thank you very much for the >>> flag. While I am only reporting activity, hope to have results soon. >>> Regards, >>> ganesh k >>> >> Hi All, >> >> bisecting changes on the wilc1000 host driver, I find that this problem >> seems to occur after the below change. >> As of now, I only know the where and not the why. So I will continue to >> figure out why this happens. >> >> commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a >> Author: Binoy Jayan >> Date: Thu Jun 23 11:11:51 2016 +0530 >> >> staging: wilc1000: Replace kthread with workqueue for host interface >> >> Deconstruct the kthread / message_queue logic, replacing it with >> create_singlethread_workqueue() / queue_work() setup, by adding a >> 'struct work_struct' to 'struct host_if_msg'. The current kthread >> hostIFthread() is converted to a work queue helper with the name >> 'host_if_work'. > > So if you revert this, it works? > > If so, let us know and I will gladly revert it, as breaking things is > not ok. > > thanks, > > greg k-h > Unfortunately no. We will have to revert this commit and the one submitted after this. The commit a5c84b2 after 2518ac5 is heavily reliant on its parent 2518ac5. Note that reverting 2518ac5 throws up a couple of minor merge conflicts which can be resolved by dropping changes in HEAD and retaining the parent commit of 2518ac5. With this, the crash is not seen anymore. Thanks! Aditya
Re: staging: wilc1000: kernel Oops while opening the device
On Fri, Sep 23, 2016 at 01:17:08PM +, aditya.shan...@microchip.com wrote: > On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote: > >> -Original Message- > >> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > >> Sent: Monday, September 19, 2016 7:12 PM > >> To: Nicolas Ferre > >> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh > >> Krishna - I00112; lui...@osg.samsung.com > >> Subject: Re: staging: wilc1000: kernel Oops while opening the device > >> > >> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote: > >>> Hi all, > >>> > >>> While using the wilc1000 driver with latest 4.8-rc7, I have > >>> difficulties to open the device and actually use it as I have this > >>> kernel Oops right after the loading of the firmware > >>> (wilc1003_firmware.bin). > >>> > >>> If I revert back the driver to its > >>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did > >>> this because I tend to think that it might be related to the latest move > >>> on this driver to "completion" or "work queues". > >>> It seems to be a regression from 4.7. > >> > >> Ick, not good at all. > >> > >> Any chance you can run 'git bisect' to see if you can find the offending > >> patch? > >> > >> I thought the maintainers were testing this driver over time :( > > > >> thanks, > >> > >> greg k-h > > > > Ick indeed. Maintainers are on it full time. Thank you very much for the > > flag. While I am only reporting activity, hope to have results soon. > > Regards, > > ganesh k > > > Hi All, > > bisecting changes on the wilc1000 host driver, I find that this problem seems > to occur after the below change. > As of now, I only know the where and not the why. So I will continue to > figure out why this happens. > > commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a > Author: Binoy Jayan > Date: Thu Jun 23 11:11:51 2016 +0530 > > staging: wilc1000: Replace kthread with workqueue for host interface > > Deconstruct the kthread / message_queue logic, replacing it with > create_singlethread_workqueue() / queue_work() setup, by adding a > 'struct work_struct' to 'struct host_if_msg'. The current kthread > hostIFthread() is converted to a work queue helper with the name > 'host_if_work'. So if you revert this, it works? If so, let us know and I will gladly revert it, as breaking things is not ok. thanks, greg k-h
Re: staging: wilc1000: kernel Oops while opening the device
On Thursday 22 September 2016 06:04 PM, Ganesh Krishna - I00112 wrote: >> -Original Message- >> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >> Sent: Monday, September 19, 2016 7:12 PM >> To: Nicolas Ferre >> Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh Krishna >> - I00112; lui...@osg.samsung.com >> Subject: Re: staging: wilc1000: kernel Oops while opening the device >> >> On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote: >>> Hi all, >>> >>> While using the wilc1000 driver with latest 4.8-rc7, I have >>> difficulties to open the device and actually use it as I have this >>> kernel Oops right after the loading of the firmware (wilc1003_firmware.bin). >>> >>> If I revert back the driver to its >>> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did >>> this because I tend to think that it might be related to the latest move on >>> this driver to "completion" or "work queues". >>> It seems to be a regression from 4.7. >> >> Ick, not good at all. >> >> Any chance you can run 'git bisect' to see if you can find the offending >> patch? >> >> I thought the maintainers were testing this driver over time :( > >> thanks, >> >> greg k-h > > Ick indeed. Maintainers are on it full time. Thank you very much for the > flag. While I am only reporting activity, hope to have results soon. > Regards, > ganesh k > Hi All, bisecting changes on the wilc1000 host driver, I find that this problem seems to occur after the below change. As of now, I only know the where and not the why. So I will continue to figure out why this happens. commit 2518ac59eb27ed003c5a97e8f9588adafdfe4a8a Author: Binoy Jayan Date: Thu Jun 23 11:11:51 2016 +0530 staging: wilc1000: Replace kthread with workqueue for host interface Deconstruct the kthread / message_queue logic, replacing it with create_singlethread_workqueue() / queue_work() setup, by adding a 'struct work_struct' to 'struct host_if_msg'. The current kthread hostIFthread() is converted to a work queue helper with the name 'host_if_work'. Thanks! Aditya
RE: staging: wilc1000: kernel Oops while opening the device
>-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Monday, September 19, 2016 7:12 PM >To: Nicolas Ferre >Cc: linux-wireless@vger.kernel.org; Aditya Shankar - I16078; Ganesh Krishna - >I00112; lui...@osg.samsung.com >Subject: Re: staging: wilc1000: kernel Oops while opening the device > >On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote: >> Hi all, >> >> While using the wilc1000 driver with latest 4.8-rc7, I have >> difficulties to open the device and actually use it as I have this >> kernel Oops right after the loading of the firmware (wilc1003_firmware.bin). >> >> If I revert back the driver to its >> b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did >> this because I tend to think that it might be related to the latest move on >> this driver to "completion" or "work queues". >> It seems to be a regression from 4.7. > >Ick, not good at all. > >Any chance you can run 'git bisect' to see if you can find the offending patch? > >I thought the maintainers were testing this driver over time :( >thanks, > >greg k-h Ick indeed. Maintainers are on it full time. Thank you very much for the flag. While I am only reporting activity, hope to have results soon. Regards, ganesh k
Re: staging: wilc1000: kernel Oops while opening the device
On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote: > Hi all, > > While using the wilc1000 driver with latest 4.8-rc7, I > have difficulties to open the device and actually use it as I have > this kernel Oops right after the loading of the firmware > (wilc1003_firmware.bin). > > If I revert back the driver to its b9811891a9f60ca9c314dcab3244c65930c4cf37 > state, > it works okay. I did this because I tend to think that it might be related to > the latest > move on this driver to "completion" or "work queues". > It seems to be a regression from 4.7. Ick, not good at all. Any chance you can run 'git bisect' to see if you can find the offending patch? I thought the maintainers were testing this driver over time :( thanks, greg k-h
staging: wilc1000: kernel Oops while opening the device
Hi all, While using the wilc1000 driver with latest 4.8-rc7, I have difficulties to open the device and actually use it as I have this kernel Oops right after the loading of the firmware (wilc1003_firmware.bin). If I revert back the driver to its b9811891a9f60ca9c314dcab3244c65930c4cf37 state, it works okay. I did this because I tend to think that it might be related to the latest move on this driver to "completion" or "work queues". It seems to be a regression from 4.7. It's on my ARM platform sama5d2 Xplained. Here is the log: --- root@sama5d2-xplained:~# ifup wlan0 Successfully initialized wpa_supplicant wilc1000_sdio mmc1:0001:1: chipid (001003a0) wilc1000_sdio mmc1:0001:1: has_thrpt_enh3 = 1... wilc1000_sdio mmc1:0001:1 wlan0: loading firmware atmel/wilc1003_firmware.bin Unable to handle kernel NULL pointer dereference at virtual address 0010 pgd = d4608000 [0010] *pgd=34671831, *pte=, *ppte= Internal error: Oops: 17 [#1] ARM Modules linked in: wilc1000_sdio(C) wilc1000(C) CPU: 0 PID: 365 Comm: wpa_supplicant Tainted: G C 4.8.0-rc7 #231 Hardware name: Atmel SAMA5 task: d463dbc0 task.stack: d462e000 PC is at __queue_work+0x98/0x29c LR is at __queue_work+0x60/0x29c pc : []lr : []psr: 6093 sp : d462fc68 ip : a093 fp : 0014 r10: r9 : 0001 r8 : c0a0812c r7 : c0a2f098 r6 : d444a900 r5 : d4663374 r4 : r3 : 0006000a r2 : d4663374 r1 : 07ff r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c53c7d Table: 34608059 DAC: 0051 Process wpa_supplicant (pid: 365, stack limit = 0xd462e208) Stack: (0xd462fc68 to 0xd463) fc60: c0a0bbc0 c985 a013 ffe1 d461a460 fc80: d444a500 8914 c0127298 d4663200 d461a460 0001 bf0076b4 fca0: fe7c bf0082b4 0018 0001 fcc0: fce0: fd00: fd20: fd40: fd60: fd80: fda0: fdc0: fde0: fe00: d461a460 fe20: d461a000 d461a800 bf00509c fe40: 0001 d461a000 bf00dde0 0001 1002 c04fde98 fe60: d461a000 d461a000 0001 d461a000 1003 c04fe128 d461a000 0148 fe80: 1002 0001 c04fe204 d444a50c 0001 fea0: c0557d5c 0020 bebd28f0 bebd28f0 d444a50c d461a000 fec0: 6e616c77 0030 1003 fee0: 1002 8914 bebd28f0 d0164000 bebd28f0 d43ceb40 d462e000 bebd28f0 ff00: d0164020 c04e40a0 0005 d43ceb40 8914 c01b16e0 d43ce008 0020 ff20: 0001 0001 d4418d80 d43ce000 0008 d4028ba8 ff40: d43ce000 0008 bebd2950 d462ff80 0008 c01a1a1c ff60: d43ce000 d43ceb40 d43ceb40 8914 bebd28f0 0005 ff80: d462e000 000f0c70 c01b1ef0 0005 0001 0036 ffa0: c01076e4 c0107520 0005 0005 8914 bebd28f0 1003 ffc0: 0005 0001 0036 0011959d 001195b9 0005 000f0c70 ffe0: 001019bc bebd28e4 000b4660 b6c761fc 600c0010 0005 [] (__queue_work) from [] (queue_work_on+0x34/0x40) [] (queue_work_on) from [] (wilc_enqueue_cmd+0x54/0x64 [wilc1000]) [] (wilc_enqueue_cmd [wilc1000]) from [] (wilc_set_wfi_drv_handler+0x48/0x70 [wilc1000]) [] (wilc_set_wfi_drv_handler [wilc1000]) from [] (wilc_mac_open+0x214/0x250 [wilc1000]) [] (wilc_mac_open [wilc1000]) from [] (__dev_open+0xb8/0x11c) [] (__dev_open) from [] (__dev_change_flags+0x94/0x158) [] (__dev_change_flags) from [] (dev_change_flags+0x18/0x48) [] (dev_change_flags) from [] (devinet_ioctl+0x6b4/0x788) [] (devinet_ioctl) from [] (sock_ioctl+0x154/0x2cc) [] (sock_ioctl) from [] (do_vfs_ioctl+0x9c/0x878) [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) Code: e5932004 e1520006 01a04003 0aff (e5943010) ---[ end trace b612328adaa6bf20 ]--- /etc/network/if-pre-up.d/wpa-supplicant: line 83: 365 Segmentation fault start-stop-daemon --start --quiet --name $WPA_SUP_PNAME --startas $WP
