Adding the devname:vhci alias and thus adding a static /dev/vhci device node
only works when assigning a fixed major/minor number. However, the code
currently uses a dynamically assigned minor number. It is therefore impossible
to create a static device and to autoload the module when accessing it.
Reverting this fixes the kmod error message
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
---
drivers/bluetooth/hci_vhci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c
index 1ef6990..cf05d70 100644
--- a/drivers/bluetooth/hci_vhci.c
+++ b/drivers/bluetooth/hci_vhci.c
@@ -384,4 +384,3 @@ MODULE_AUTHOR("Marcel Holtmann <[email protected]>");
MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE("GPL");
-MODULE_ALIAS("devname:vhci");
--
1.9.0
Hi Thomas
On Wed, Mar 5, 2014 at 3:48 PM, Thomas B=C3=A4chler <[email protected]> =
wrote:
> Am 05.03.2014 19:36, schrieb Marcel Holtmann:
>>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>>
>>>> NAK. We allocated a static minor for this.
>>>
>>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>>> correct?
>
> I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
> bluetooth-next. This commit should indeed fix the problem. Disregard my
> patch.
>
>> Why isn't that headed into 3.14 right now, and CC'd to
>>> stable? Currently you have a somewhat broken driver in 3.13 and
>>> 3.14-rcX that seems to have a pretty clear fix.
>>
>> somewhat broken? kmod prints this as an error, but it is not a regressio=
n in user functionality. The driver works just as before. The error message=
can be ignored.
>
> It's a regression in my sanity, since numerous users blame all kernel
> bugs on this error message and I am tired of explaining the situation
> (problem + error message =3D=3D problem found *sigh*). I only sent this
> patch since I hadn't found the correct fix.
Feel free to CC kmod mailing list in these cases
([email protected]). We've added this message to kmod
exactly to catch problems like this and help people doing the drivers.
Once I found out the problem with vhci I sent the patch to fix it,
which is heading to Linus tree.
--=20
Lucas De Marchi
Hi Josh,
>>>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>>>
>>>>> NAK. We allocated a static minor for this.
>>>>
>>>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>>>> correct?
>>
>> I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
>> bluetooth-next. This commit should indeed fix the problem. Disregard my
>> patch.
>>
>>> Why isn't that headed into 3.14 right now, and CC'd to
>>>> stable? Currently you have a somewhat broken driver in 3.13 and
>>>> 3.14-rcX that seems to have a pretty clear fix.
>>>
>>> somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
>>
>> It's a regression in my sanity, since numerous users blame all kernel
>> bugs on this error message and I am tired of explaining the situation
>> (problem + error message == problem found *sigh*). I only sent this
>> patch since I hadn't found the correct fix.
>
> Exactly.
>
>>> So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
>>
>> Since b075dd4 will end up in the Linus tree eventually, I have no
>> trouble backporting it myself.
>
> I don't have any difficulty doing that either, but if it was in stable
> every distro getting bugs about it wouldn't have to carry the fix on
> their own.
the patch is currently in wireless-next and will eventually end up in net-next. Maybe it is better to have it cherry picked once it reaches net-next.
Regards
Marcel
On Wed, Mar 5, 2014 at 1:48 PM, Thomas B=E4chler <[email protected]> wro=
te:
> Am 05.03.2014 19:36, schrieb Marcel Holtmann:
>>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>>
>>>> NAK. We allocated a static minor for this.
>>>
>>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>>> correct?
>
> I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
> bluetooth-next. This commit should indeed fix the problem. Disregard my
> patch.
>
>> Why isn't that headed into 3.14 right now, and CC'd to
>>> stable? Currently you have a somewhat broken driver in 3.13 and
>>> 3.14-rcX that seems to have a pretty clear fix.
>>
>> somewhat broken? kmod prints this as an error, but it is not a regressio=
n in user functionality. The driver works just as before. The error message=
can be ignored.
>
> It's a regression in my sanity, since numerous users blame all kernel
> bugs on this error message and I am tired of explaining the situation
> (problem + error message =3D=3D problem found *sigh*). I only sent this
> patch since I hadn't found the correct fix.
Exactly.
>> So if anybody feels strongly that the static device node assignment shou=
ld be put into -stable, then I am fine with it. However I do not see this a=
s passing requirement for a -stable fix since it is really not affecting an=
yone (minus the misleading message from kmod).
>
> Since b075dd4 will end up in the Linus tree eventually, I have no
> trouble backporting it myself.
I don't have any difficulty doing that either, but if it was in stable
every distro getting bugs about it wouldn't have to carry the fix on
their own.
josh
Am 05.03.2014 19:36, schrieb Marcel Holtmann:
>>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>
>>> NAK. We allocated a static minor for this.
>>
>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>> correct?
I am sorry Marcel, I only looked at the Linus tree, not at bluetooth or
bluetooth-next. This commit should indeed fix the problem. Disregard my
patch.
> Why isn't that headed into 3.14 right now, and CC'd to
>> stable? Currently you have a somewhat broken driver in 3.13 and
>> 3.14-rcX that seems to have a pretty clear fix.
>
> somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
It's a regression in my sanity, since numerous users blame all kernel
bugs on this error message and I am tired of explaining the situation
(problem + error message == problem found *sigh*). I only sent this
patch since I hadn't found the correct fix.
> So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
Since b075dd4 will end up in the Linus tree eventually, I have no
trouble backporting it myself.
Sorry for the disturbance.
Hi Josh,
>>> Adding the devname:vhci alias and thus adding a static /dev/vhci device node
>>> only works when assigning a fixed major/minor number. However, the code
>>> currently uses a dynamically assigned minor number. It is therefore impossible
>>> to create a static device and to autoload the module when accessing it.
>>>
>>> Reverting this fixes the kmod error message
>>> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
>>>
>>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>
>> NAK. We allocated a static minor for this.
>
> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
> correct? Why isn't that headed into 3.14 right now, and CC'd to
> stable? Currently you have a somewhat broken driver in 3.13 and
> 3.14-rcX that seems to have a pretty clear fix.
somewhat broken? kmod prints this as an error, but it is not a regression in user functionality. The driver works just as before. The error message can be ignored.
So if anybody feels strongly that the static device node assignment should be put into -stable, then I am fine with it. However I do not see this as passing requirement for a -stable fix since it is really not affecting anyone (minus the misleading message from kmod).
Regards
Marcel
On Wed, Mar 5, 2014 at 11:46 AM, Marcel Holtmann <[email protected]> wrote:
> Hi Thomas,
>
>> Adding the devname:vhci alias and thus adding a static /dev/vhci device node
>> only works when assigning a fixed major/minor number. However, the code
>> currently uses a dynamically assigned minor number. It is therefore impossible
>> to create a static device and to autoload the module when accessing it.
>>
>> Reverting this fixes the kmod error message
>> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
>>
>> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>
> NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
correct? Why isn't that headed into 3.14 right now, and CC'd to
stable? Currently you have a somewhat broken driver in 3.13 and
3.14-rcX that seems to have a pretty clear fix.
josh
Hi Thomas,
> Adding the devname:vhci alias and thus adding a static /dev/vhci device node
> only works when assigning a fixed major/minor number. However, the code
> currently uses a dynamically assigned minor number. It is therefore impossible
> to create a static device and to autoload the module when accessing it.
>
> Reverting this fixes the kmod error message
> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
>
> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Regards
Marcel
Hi,
On Wed, Mar 05, 2014, Josh Boyer wrote:
> On Wed, Mar 5, 2014 at 6:59 AM, Thomas B?chler <[email protected]> wrote:
> > Adding the devname:vhci alias and thus adding a static /dev/vhci device node
> > only works when assigning a fixed major/minor number. However, the code
> > currently uses a dynamically assigned minor number. It is therefore impossible
> > to create a static device and to autoload the module when accessing it.
> >
> > Reverting this fixes the kmod error message
> > depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
> >
> > This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>
> We've had several reports of this in Fedora as well. I hadn't gotten
> around to digging into it yet, so thanks for bringing this up Thomas.
How does this relate to the "Bluetooth: allocate static minor for vhci"
patch that we have in the bluetooth-next tree (also in wireless-next,
going to the 3.15 kernel). It's commit b075dd40c95d11c2c8690f6c4d6232fc.
Johan
On Wed, Mar 5, 2014 at 6:59 AM, Thomas B=E4chler <[email protected]> wro=
te:
> Adding the devname:vhci alias and thus adding a static /dev/vhci device n=
ode
> only works when assigning a fixed major/minor number. However, the code
> currently uses a dynamically assigned minor number. It is therefore impos=
sible
> to create a static device and to autoload the module when accessing it.
>
> Reverting this fixes the kmod error message
> depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and =
minor information. Ignoring.
>
> This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
We've had several reports of this in Fedora as well. I hadn't gotten
around to digging into it yet, so thanks for bringing this up Thomas.
josh
> ---
> drivers/bluetooth/hci_vhci.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c
> index 1ef6990..cf05d70 100644
> --- a/drivers/bluetooth/hci_vhci.c
> +++ b/drivers/bluetooth/hci_vhci.c
> @@ -384,4 +384,3 @@ MODULE_AUTHOR("Marcel Holtmann <[email protected]>"=
);
> MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
> MODULE_VERSION(VERSION);
> MODULE_LICENSE("GPL");
> -MODULE_ALIAS("devname:vhci");
> --
> 1.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/