On Saturday, July 20, 2013 11:51:55 AM Rafael J. Wysocki wrote:
> On Saturday, July 20, 2013 05:06:29 AM Rafael J. Wysocki wrote:
> > On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
> > > On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
> > > > On Fri, Jul 19, 2013 at
On Saturday, July 20, 2013 05:06:29 AM Rafael J. Wysocki wrote:
> On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
> > On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
> > > On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
> > > > Alas, this is not
On Saturday, July 20, 2013 05:06:29 AM Rafael J. Wysocki wrote:
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd
On Saturday, July 20, 2013 11:51:55 AM Rafael J. Wysocki wrote:
On Saturday, July 20, 2013 05:06:29 AM Rafael J. Wysocki wrote:
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
On Fri, Jul 19, 2013 at
On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
>
> However, when I have the library and generic algorithm compiled in,
> I do not see the PCLMULQDQ version loaded.
>
> CONFIG_CRYPTO_CRCT10DIF=y
> CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
> CONFIG_CRC_T10DIF=y
That is completely expected. I
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
> On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
> > On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
> > > Alas, this is not the one I'd like to apply.
> > >
> > > With that patch applied, new
On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
> On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
> > On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
> > >
> > > The issue here seems to be the dynamic binding nature of the crypto
> > > subsystem. When something needs
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
> On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
> > Alas, this is not the one I'd like to apply.
> >
> > With that patch applied, new device objects are created to avoid binding the
> > processor driver directly
On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
> On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
> >
> > The issue here seems to be the dynamic binding nature of the crypto
> > subsystem. When something needs crypto, it will request the appropriate
> > crypto module (e.g.
On 07/19/2013 04:26 PM, Greg Kroah-Hartman wrote:
>>
>> RAID has effectively the same issue, and we just "solved" it by
>> compiling in all the accelerators into the top-level module.
>
> Then there's nothing to be done in udev or kmod, right?
>
I don't know.
-hpa
--
To unsubscribe
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
> On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
> >
> > udev isn't doing any module loading, 'modprobe' is just being called for
> > any new module alias that shows up in the system, and all of the drivers
> > that match it then
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
>
> The issue here seems to be the dynamic binding nature of the crypto
> subsystem. When something needs crypto, it will request the appropriate
> crypto module (e.g. crct10dif), which may race with detecting a specific
> hardware
On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
>
> udev isn't doing any module loading, 'modprobe' is just being called for
> any new module alias that shows up in the system, and all of the drivers
> that match it then get loaded.
>
> How is it a problem if a module is attempted to be loaded
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
> Alas, this is not the one I'd like to apply.
>
> With that patch applied, new device objects are created to avoid binding the
> processor driver directly to the cpu system device objects, because that
> apparently confuses udev
On Friday, July 19, 2013 11:08:49 AM Tim Chen wrote:
> On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
> > > > > > This should cause udev to load the crct10dif_pclml module when cpu
> > > > > > support the PCLMULQDQ (feature code 0081). I did my testing during
> > > > > > development
On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
> > > > > This should cause udev to load the crct10dif_pclml module when cpu
> > > > > support the PCLMULQDQ (feature code 0081). I did my testing during
> > > > > development on 3.10 and the module was indeed loaded.
> > > > >
> > > > >
On Friday, July 19, 2013 03:03:36 PM Rafael J. Wysocki wrote:
> On Thursday, July 18, 2013 04:08:14 PM Tim Chen wrote:
> > On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
> > > On 7/18/2013 11:00 PM, Tim Chen wrote:
> > > > On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
> > >
On Thursday, July 18, 2013 04:08:14 PM Tim Chen wrote:
> On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
> > On 7/18/2013 11:00 PM, Tim Chen wrote:
> > > On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
> > >> Tim Chen wrote:
> > > Your approach is quite complicated. I think
On Thursday, July 18, 2013 04:44:20 PM H. Peter Anvin wrote:
> On 07/18/2013 03:17 PM, Rafael J. Wysocki wrote:
> >>
> >> alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
> >>
> >> This should cause udev to load the crct10dif_pclml module when cpu
> >> support the PCLMULQDQ
On Thursday, July 18, 2013 04:44:20 PM H. Peter Anvin wrote:
On 07/18/2013 03:17 PM, Rafael J. Wysocki wrote:
alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code
On Thursday, July 18, 2013 04:08:14 PM Tim Chen wrote:
On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
On 7/18/2013 11:00 PM, Tim Chen wrote:
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something
On Friday, July 19, 2013 03:03:36 PM Rafael J. Wysocki wrote:
On Thursday, July 18, 2013 04:08:14 PM Tim Chen wrote:
On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
On 7/18/2013 11:00 PM, Tim Chen wrote:
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen
On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code 0081). I did my testing during
development on 3.10 and the module was indeed loaded.
However, I found that
On Friday, July 19, 2013 11:08:49 AM Tim Chen wrote:
On Fri, 2013-07-19 at 16:49 +0200, Rafael J. Wysocki wrote:
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code 0081). I did my testing during
development on 3.10 and the
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.
With that patch applied, new device objects are created to avoid binding the
processor driver directly to the cpu system device objects, because that
apparently confuses udev and
On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
udev isn't doing any module loading, 'modprobe' is just being called for
any new module alias that shows up in the system, and all of the drivers
that match it then get loaded.
How is it a problem if a module is attempted to be loaded that
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
The issue here seems to be the dynamic binding nature of the crypto
subsystem. When something needs crypto, it will request the appropriate
crypto module (e.g. crct10dif), which may race with detecting a specific
hardware
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
On 07/19/2013 04:16 PM, Greg Kroah-Hartman wrote:
udev isn't doing any module loading, 'modprobe' is just being called for
any new module alias that shows up in the system, and all of the drivers
that match it then get
On 07/19/2013 04:26 PM, Greg Kroah-Hartman wrote:
RAID has effectively the same issue, and we just solved it by
compiling in all the accelerators into the top-level module.
Then there's nothing to be done in udev or kmod, right?
I don't know.
-hpa
--
To unsubscribe from this
On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
The issue here seems to be the dynamic binding nature of the crypto
subsystem. When something needs crypto, it will request the appropriate
crypto module (e.g. crct10dif),
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.
With that patch applied, new device objects are created to avoid binding the
processor driver directly to the cpu
On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
On Sat, 2013-07-20 at 09:24 +1000, Herbert Xu wrote:
On Fri, Jul 19, 2013 at 04:21:09PM -0700, H. Peter Anvin wrote:
The issue here seems to be the dynamic binding nature of the crypto
subsystem. When something needs crypto, it will
On Saturday, July 20, 2013 02:00:44 AM Rafael J. Wysocki wrote:
On Friday, July 19, 2013 04:16:30 PM Greg Kroah-Hartman wrote:
On Fri, Jul 19, 2013 at 11:38:04PM +0200, Rafael J. Wysocki wrote:
Alas, this is not the one I'd like to apply.
With that patch applied, new device objects
On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
However, when I have the library and generic algorithm compiled in,
I do not see the PCLMULQDQ version loaded.
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRC_T10DIF=y
That is completely expected. I don't
On 07/18/2013 03:17 PM, Rafael J. Wysocki wrote:
>>
>> alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
>>
>> This should cause udev to load the crct10dif_pclml module when cpu
>> support the PCLMULQDQ (feature code 0081). I did my testing during
>> development on 3.10 and
On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
> On 7/18/2013 11:00 PM, Tim Chen wrote:
> > On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
> >> Tim Chen wrote:
> > Your approach is quite complicated. I think something simpler like the
> > following will work:
>
On 7/18/2013 11:00 PM, Tim Chen wrote:
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from PCLMULQDQ. Is it acceptable for you?
The following code in
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
> Tim Chen wrote:
> > > > Your approach is quite complicated. I think something simpler like the
> > > > following will work:
> > >
> > > We cannot benefit from PCLMULQDQ. Is it acceptable for you?
> >
> >
> > The following code in
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from PCLMULQDQ. Is it acceptable for you?
The following code in crct10dif-pclmul_glue.c
On 7/18/2013 11:00 PM, Tim Chen wrote:
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from PCLMULQDQ. Is it acceptable for you?
The following code in
On Fri, 2013-07-19 at 00:17 +0200, Rafael J. Wysocki wrote:
On 7/18/2013 11:00 PM, Tim Chen wrote:
On Thu, 2013-07-18 at 12:47 +0900, Tetsuo Handa wrote:
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from
On 07/18/2013 03:17 PM, Rafael J. Wysocki wrote:
alias x86cpu:vendor:*:family:*:model:*:feature:*0081* crct10dif_pclmul
This should cause udev to load the crct10dif_pclml module when cpu
support the PCLMULQDQ (feature code 0081). I did my testing during
development on 3.10 and the module
Tim Chen wrote:
> > > Your approach is quite complicated. I think something simpler like the
> > > following will work:
> >
> > We cannot benefit from PCLMULQDQ. Is it acceptable for you?
>
>
> The following code in crct10dif-pclmul_glue.c
>
> static const struct x86_cpu_id crct10dif_cpu_id[]
Tim Chen wrote:
Your approach is quite complicated. I think something simpler like the
following will work:
We cannot benefit from PCLMULQDQ. Is it acceptable for you?
The following code in crct10dif-pclmul_glue.c
static const struct x86_cpu_id crct10dif_cpu_id[] = {
On Tue, Jul 16, 2013 at 08:53:02PM +0900, Tetsuo Handa wrote:
> I got below failure.
>
> [5.258911] scsi 1:0:0:0: CD-ROMNECVMWar VMware IDE CDR10
> 1.00 PQ: 0 ANSI: 5
> [5.267651] modprobe (156) used greatest stack depth: 4064 bytes left
> [5.293607] Fusion MPT base
Jul 2013 18:33:40 +0900
Subject: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
Commit 2d31e518 "crypto: crct10dif - Wrap crc_t10dif function all to use crypto
transform framework" was added without updating module dependency, breaking at
least one module which dep
, 16 Jul 2013 18:33:40 +0900
Subject: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
Commit 2d31e518 crypto: crct10dif - Wrap crc_t10dif function all to use crypto
transform framework was added without updating module dependency, breaking at
least one module which depends
On Tue, Jul 16, 2013 at 08:53:02PM +0900, Tetsuo Handa wrote:
I got below failure.
[5.258911] scsi 1:0:0:0: CD-ROMNECVMWar VMware IDE CDR10
1.00 PQ: 0 ANSI: 5
[5.267651] modprobe (156) used greatest stack depth: 4064 bytes left
[5.293607] Fusion MPT base
48 matches
Mail list logo
