* [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"
@ 2021-12-09 23:36 coldolt
2021-12-10 1:10 ` An, Tedd
0 siblings, 1 reply; 6+ messages in thread
From: coldolt @ 2021-12-09 23:36 UTC (permalink / raw)
To: marcel, kai.heng.feng, tedd.an, linux-bluetooth; +Cc: linux-kernel, regressions
After a restart, bluetooth doesn't work since commit 0ea53674d07f
"Bluetooth: Move shutdown callback before flushing tx and rx queue"
bluetoothctl doesn't list any controllers and I get the following in
dmesg | grep -i bluetooth
[ 2.634812] Bluetooth: Core ver 2.22
[ 2.634843] NET: Registered PF_BLUETOOTH protocol family
[ 2.634845] Bluetooth: HCI device and connection manager initialized
[ 2.634850] Bluetooth: HCI socket layer initialized
[ 2.634853] Bluetooth: L2CAP socket layer initialized
[ 2.634858] Bluetooth: SCO socket layer initialized
[ 4.077788] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 4.077794] Bluetooth: BNEP filters: protocol multicast
[ 4.077799] Bluetooth: BNEP socket layer initialized
[ 4.078219] random: bluetoothd: uninitialized urandom read (4 bytes read)
[ 4.852835] Bluetooth: hci0: Reading Intel version command failed (-110)
[ 4.852838] Bluetooth: hci0: command 0xfc05 tx timeout
However, it works after a cold start or after putting the computer to sleep.
Before 83f2dafe2a62 "Bluetooth: btintel: Refactoring setup routine for
legacy ROM sku", it always works after a restart, but from that commit
up until before 0ea53674d07f it either works or doesn't work after a
restart depending on if before restart it was working or not, meaning
it stays working or stays not working.
Also on the first restart from before 83f2dafe2a62 into 0ea53674d07f
or later it works, but then restarting again into 0ea53674d07f or
later it no longer works. So it seems that 0ea53674d07f and later puts
the bluetooth in a nonworking state if you restart from it, but before
83f2dafe2a62 it puts it back into a working state at startup, and in
between it doesn't do either, i.e. it stays the way it was.
I have a Dell Latitude E5550 laptop with an Intel 7265 wifi/bluetooth
card REV=0x210 firmware version 29.4063824552.0 7265D-29. I'm on Arch
Linux, the problem is still there on 5.16-rc4.
Here is a thread on the Arch Linux forums with several people with the
same problem, for some of them it got fixed with a kernel update or by
reloading modules, but not for everybody, including me
https://bbs.archlinux.org/viewtopic.php?id=271459
#regzbot introduced 0ea53674d07f
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"
2021-12-09 23:36 [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue" coldolt
@ 2021-12-10 1:10 ` An, Tedd
2021-12-10 9:16 ` Thorsten Leemhuis
0 siblings, 1 reply; 6+ messages in thread
From: An, Tedd @ 2021-12-10 1:10 UTC (permalink / raw)
To: kai.heng.feng, andypalmadi, marcel, linux-bluetooth
Cc: linux-kernel, regressions
Hi,
On Fri, 2021-12-10 at 01:36 +0200, coldolt wrote:
> After a restart, bluetooth doesn't work since commit 0ea53674d07f
> "Bluetooth: Move shutdown callback before flushing tx and rx queue"
>
> bluetoothctl doesn't list any controllers and I get the following in
> dmesg | grep -i bluetooth
>
> [ 2.634812] Bluetooth: Core ver 2.22
> [ 2.634843] NET: Registered PF_BLUETOOTH protocol family
> [ 2.634845] Bluetooth: HCI device and connection manager initialized
> [ 2.634850] Bluetooth: HCI socket layer initialized
> [ 2.634853] Bluetooth: L2CAP socket layer initialized
> [ 2.634858] Bluetooth: SCO socket layer initialized
> [ 4.077788] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 4.077794] Bluetooth: BNEP filters: protocol multicast
> [ 4.077799] Bluetooth: BNEP socket layer initialized
> [ 4.078219] random: bluetoothd: uninitialized urandom read (4 bytes read)
> [ 4.852835] Bluetooth: hci0: Reading Intel version command failed (-110)
> [ 4.852838] Bluetooth: hci0: command 0xfc05 tx timeout
>
> However, it works after a cold start or after putting the computer to sleep.
>
> Before 83f2dafe2a62 "Bluetooth: btintel: Refactoring setup routine for
> legacy ROM sku", it always works after a restart, but from that commit
> up until before 0ea53674d07f it either works or doesn't work after a
> restart depending on if before restart it was working or not, meaning
> it stays working or stays not working.
>
> Also on the first restart from before 83f2dafe2a62 into 0ea53674d07f
> or later it works, but then restarting again into 0ea53674d07f or
> later it no longer works. So it seems that 0ea53674d07f and later puts
> the bluetooth in a nonworking state if you restart from it, but before
> 83f2dafe2a62 it puts it back into a working state at startup, and in
> between it doesn't do either, i.e. it stays the way it was.
>
> I have a Dell Latitude E5550 laptop with an Intel 7265 wifi/bluetooth
> card REV=0x210 firmware version 29.4063824552.0 7265D-29. I'm on Arch
> Linux, the problem is still there on 5.16-rc4.
>
> Here is a thread on the Arch Linux forums with several people with the
> same problem, for some of them it got fixed with a kernel update or by
> reloading modules, but not for everybody, including me
> https://bbs.archlinux.org/viewtopic.php?id=271459
>
> #regzbot introduced 0ea53674d07f
This issue is under investigation to find the root cause and proper solution.
The downloaded firmware breaks the behavior though, we need to investigate
further to see if it can be fixed in firmware or fix in the driver.
Regards,
Tedd
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"
2021-12-10 1:10 ` An, Tedd
@ 2021-12-10 9:16 ` Thorsten Leemhuis
2022-01-20 13:08 ` Thorsten Leemhuis
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Leemhuis @ 2021-12-10 9:16 UTC (permalink / raw)
To: An, Tedd, kai.heng.feng, andypalmadi, marcel, linux-bluetooth
Cc: linux-kernel, regressions
Hi, this is your Linux kernel regression tracker speaking.
On 10.12.21 02:10, An, Tedd wrote:
> On Fri, 2021-12-10 at 01:36 +0200, coldolt wrote:
>> After a restart, bluetooth doesn't work since commit 0ea53674d07f
>> "Bluetooth: Move shutdown callback before flushing tx and rx queue"
>>
>> bluetoothctl doesn't list any controllers and I get the following in
>> dmesg | grep -i bluetooth
>>
>> [ 2.634812] Bluetooth: Core ver 2.22
>> [ 2.634843] NET: Registered PF_BLUETOOTH protocol family
>> [ 2.634845] Bluetooth: HCI device and connection manager initialized
>> [ 2.634850] Bluetooth: HCI socket layer initialized
>> [ 2.634853] Bluetooth: L2CAP socket layer initialized
>> [ 2.634858] Bluetooth: SCO socket layer initialized
>> [ 4.077788] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> [ 4.077794] Bluetooth: BNEP filters: protocol multicast
>> [ 4.077799] Bluetooth: BNEP socket layer initialized
>> [ 4.078219] random: bluetoothd: uninitialized urandom read (4 bytes read)
>> [ 4.852835] Bluetooth: hci0: Reading Intel version command failed (-110)
>> [ 4.852838] Bluetooth: hci0: command 0xfc05 tx timeout
>>
>> However, it works after a cold start or after putting the computer to sleep.
>>
>> Before 83f2dafe2a62 "Bluetooth: btintel: Refactoring setup routine for
>> legacy ROM sku", it always works after a restart, but from that commit
>> up until before 0ea53674d07f it either works or doesn't work after a
>> restart depending on if before restart it was working or not, meaning
>> it stays working or stays not working.
>>
>> Also on the first restart from before 83f2dafe2a62 into 0ea53674d07f
>> or later it works, but then restarting again into 0ea53674d07f or
>> later it no longer works. So it seems that 0ea53674d07f and later puts
>> the bluetooth in a nonworking state if you restart from it, but before
>> 83f2dafe2a62 it puts it back into a working state at startup, and in
>> between it doesn't do either, i.e. it stays the way it was.
>>
>> I have a Dell Latitude E5550 laptop with an Intel 7265 wifi/bluetooth
>> card REV=0x210 firmware version 29.4063824552.0 7265D-29. I'm on Arch
>> Linux, the problem is still there on 5.16-rc4.
>>
>> Here is a thread on the Arch Linux forums with several people with the
>> same problem, for some of them it got fixed with a kernel update or by
>> reloading modules, but not for everybody, including me
>> https://bbs.archlinux.org/viewtopic.php?id=271459
>>
>> #regzbot introduced 0ea53674d07f
Many thx for directly getting regzbot involved! :-D
> This issue is under investigation to find the root cause and proper solution.
Only internally? Or are there any other related public discussions that
are relevant to this and thus good to be aware of?
> The downloaded firmware breaks the behavior though, we need to investigate
> further to see if it can be fixed in firmware or fix in the driver.
The answer from my point is simple: it needs to be fixed in the kernel,
not just in the firmware, otherwise people that update the kernel
without updating the firmware at the same time will run into a
regression -- and that is not acceptable by kernel development standards.
Ciao, Thorsten
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave they thus might sent someone reading this down the
wrong rabbit hole, which none of us wants.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"
2021-12-10 9:16 ` Thorsten Leemhuis
@ 2022-01-20 13:08 ` Thorsten Leemhuis
2022-01-23 9:28 ` Thorsten Leemhuis
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Leemhuis @ 2022-01-20 13:08 UTC (permalink / raw)
To: An, Tedd, kai.heng.feng, andypalmadi, marcel, linux-bluetooth
Cc: linux-kernel, regressions
On 10.12.21 10:16, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker speaking.
/me again
> On 10.12.21 02:10, An, Tedd wrote:
>> On Fri, 2021-12-10 at 01:36 +0200, coldolt wrote:
>>> After a restart, bluetooth doesn't work since commit 0ea53674d07f
>>> "Bluetooth: Move shutdown callback before flushing tx and rx queue"
>>>
>>> bluetoothctl doesn't list any controllers and I get the following in
>>> dmesg | grep -i bluetooth
>>>
>>> [ 2.634812] Bluetooth: Core ver 2.22
>>> [ 2.634843] NET: Registered PF_BLUETOOTH protocol family
>>> [ 2.634845] Bluetooth: HCI device and connection manager initialized
>>> [ 2.634850] Bluetooth: HCI socket layer initialized
>>> [ 2.634853] Bluetooth: L2CAP socket layer initialized
>>> [ 2.634858] Bluetooth: SCO socket layer initialized
>>> [ 4.077788] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>>> [ 4.077794] Bluetooth: BNEP filters: protocol multicast
>>> [ 4.077799] Bluetooth: BNEP socket layer initialized
>>> [ 4.078219] random: bluetoothd: uninitialized urandom read (4 bytes read)
>>> [ 4.852835] Bluetooth: hci0: Reading Intel version command failed (-110)
>>> [ 4.852838] Bluetooth: hci0: command 0xfc05 tx timeout
>>>
>>> However, it works after a cold start or after putting the computer to sleep.
>>>
>>> Before 83f2dafe2a62 "Bluetooth: btintel: Refactoring setup routine for
>>> legacy ROM sku", it always works after a restart, but from that commit
>>> up until before 0ea53674d07f it either works or doesn't work after a
>>> restart depending on if before restart it was working or not, meaning
>>> it stays working or stays not working.
>>>
>>> Also on the first restart from before 83f2dafe2a62 into 0ea53674d07f
>>> or later it works, but then restarting again into 0ea53674d07f or
>>> later it no longer works. So it seems that 0ea53674d07f and later puts
>>> the bluetooth in a nonworking state if you restart from it, but before
>>> 83f2dafe2a62 it puts it back into a working state at startup, and in
>>> between it doesn't do either, i.e. it stays the way it was.
>>>
>>> I have a Dell Latitude E5550 laptop with an Intel 7265 wifi/bluetooth
>>> card REV=0x210 firmware version 29.4063824552.0 7265D-29. I'm on Arch
>>> Linux, the problem is still there on 5.16-rc4.
>>>
>>> Here is a thread on the Arch Linux forums with several people with the
>>> same problem, for some of them it got fixed with a kernel update or by
>>> reloading modules, but not for everybody, including me
>>> https://bbs.archlinux.org/viewtopic.php?id=271459
>>>
>>> #regzbot introduced 0ea53674d07f
>
> Many thx for directly getting regzbot involved! :-D
>
>> This issue is under investigation to find the root cause and proper solution.
>
> Only internally? Or are there any other related public discussions that
> are relevant to this and thus good to be aware of?
What's the status here? It looks like there was no progress since 41
days, which is awfully long even with the festive season in between.
Could anyone provide a status update please?
Ciao, Thorsten
#regzbot poke
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply, that's in everyone's interest.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
>> The downloaded firmware breaks the behavior though, we need to investigate
>> further to see if it can be fixed in firmware or fix in the driver.
>
> The answer from my point is simple: it needs to be fixed in the kernel,
> not just in the firmware, otherwise people that update the kernel
> without updating the firmware at the same time will run into a
> regression -- and that is not acceptable by kernel development standards.
>
> Ciao, Thorsten
>
> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
> on my table. I can only look briefly into most of them. Unfortunately
> therefore I sometimes will get things wrong or miss something important.
> I hope that's not the case here; if you think it is, don't hesitate to
> tell me about it in a public reply. That's in everyone's interest, as
> what I wrote above might be misleading to everyone reading this; any
> suggestion I gave they thus might sent someone reading this down the
> wrong rabbit hole, which none of us wants.
>
> BTW, I have no personal interest in this issue, which is tracked using
> regzbot, my Linux kernel regression tracking bot
> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
> this mail to get things rolling again and hence don't need to be CC on
> all further activities wrt to this regression.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"
2022-01-20 13:08 ` Thorsten Leemhuis
@ 2022-01-23 9:28 ` Thorsten Leemhuis
2022-01-23 20:11 ` coldolt
0 siblings, 1 reply; 6+ messages in thread
From: Thorsten Leemhuis @ 2022-01-23 9:28 UTC (permalink / raw)
To: An, Tedd, kai.heng.feng, andypalmadi, marcel, linux-bluetooth
Cc: linux-kernel, regressions
Top-posting for once, to make this easy accessible to everyone.
Coldolt, could you please check if this regression is still in 5.17-rc1
or 5.16.2? I wonder if this patch fixed things:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=8e8cae520210139aab4b701a822bbefb13b8f007
Ciao, Thorsten
#regzbot poke
On 20.01.22 14:08, Thorsten Leemhuis wrote:
> On 10.12.21 10:16, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker speaking.
>
> /me again
>
>> On 10.12.21 02:10, An, Tedd wrote:
>>> On Fri, 2021-12-10 at 01:36 +0200, coldolt wrote:
>>>> After a restart, bluetooth doesn't work since commit 0ea53674d07f
>>>> "Bluetooth: Move shutdown callback before flushing tx and rx queue"
>>>>
>>>> bluetoothctl doesn't list any controllers and I get the following in
>>>> dmesg | grep -i bluetooth
>>>>
>>>> [ 2.634812] Bluetooth: Core ver 2.22
>>>> [ 2.634843] NET: Registered PF_BLUETOOTH protocol family
>>>> [ 2.634845] Bluetooth: HCI device and connection manager initialized
>>>> [ 2.634850] Bluetooth: HCI socket layer initialized
>>>> [ 2.634853] Bluetooth: L2CAP socket layer initialized
>>>> [ 2.634858] Bluetooth: SCO socket layer initialized
>>>> [ 4.077788] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>>>> [ 4.077794] Bluetooth: BNEP filters: protocol multicast
>>>> [ 4.077799] Bluetooth: BNEP socket layer initialized
>>>> [ 4.078219] random: bluetoothd: uninitialized urandom read (4 bytes read)
>>>> [ 4.852835] Bluetooth: hci0: Reading Intel version command failed (-110)
>>>> [ 4.852838] Bluetooth: hci0: command 0xfc05 tx timeout
>>>>
>>>> However, it works after a cold start or after putting the computer to sleep.
>>>>
>>>> Before 83f2dafe2a62 "Bluetooth: btintel: Refactoring setup routine for
>>>> legacy ROM sku", it always works after a restart, but from that commit
>>>> up until before 0ea53674d07f it either works or doesn't work after a
>>>> restart depending on if before restart it was working or not, meaning
>>>> it stays working or stays not working.
>>>>
>>>> Also on the first restart from before 83f2dafe2a62 into 0ea53674d07f
>>>> or later it works, but then restarting again into 0ea53674d07f or
>>>> later it no longer works. So it seems that 0ea53674d07f and later puts
>>>> the bluetooth in a nonworking state if you restart from it, but before
>>>> 83f2dafe2a62 it puts it back into a working state at startup, and in
>>>> between it doesn't do either, i.e. it stays the way it was.
>>>>
>>>> I have a Dell Latitude E5550 laptop with an Intel 7265 wifi/bluetooth
>>>> card REV=0x210 firmware version 29.4063824552.0 7265D-29. I'm on Arch
>>>> Linux, the problem is still there on 5.16-rc4.
>>>>
>>>> Here is a thread on the Arch Linux forums with several people with the
>>>> same problem, for some of them it got fixed with a kernel update or by
>>>> reloading modules, but not for everybody, including me
>>>> https://bbs.archlinux.org/viewtopic.php?id=271459
>>>>
>>>> #regzbot introduced 0ea53674d07f
>>
>> Many thx for directly getting regzbot involved! :-D
>>
>>> This issue is under investigation to find the root cause and proper solution.
>>
>> Only internally? Or are there any other related public discussions that
>> are relevant to this and thus good to be aware of?
>
> What's the status here? It looks like there was no progress since 41
> days, which is awfully long even with the festive season in between.
> Could anyone provide a status update please?
>
> Ciao, Thorsten
>
> #regzbot poke
>
> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
> on my table. I can only look briefly into most of them. Unfortunately
> therefore I sometimes will get things wrong or miss something important.
> I hope that's not the case here; if you think it is, don't hesitate to
> tell me about it in a public reply, that's in everyone's interest.
>
> BTW, I have no personal interest in this issue, which is tracked using
> regzbot, my Linux kernel regression tracking bot
> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
> this mail to get things rolling again and hence don't need to be CC on
> all further activities wrt to this regression.
>
>>> The downloaded firmware breaks the behavior though, we need to investigate
>>> further to see if it can be fixed in firmware or fix in the driver.
>>
>> The answer from my point is simple: it needs to be fixed in the kernel,
>> not just in the firmware, otherwise people that update the kernel
>> without updating the firmware at the same time will run into a
>> regression -- and that is not acceptable by kernel development standards.
>>
>> Ciao, Thorsten
>>
>> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
>> on my table. I can only look briefly into most of them. Unfortunately
>> therefore I sometimes will get things wrong or miss something important.
>> I hope that's not the case here; if you think it is, don't hesitate to
>> tell me about it in a public reply. That's in everyone's interest, as
>> what I wrote above might be misleading to everyone reading this; any
>> suggestion I gave they thus might sent someone reading this down the
>> wrong rabbit hole, which none of us wants.
>>
>> BTW, I have no personal interest in this issue, which is tracked using
>> regzbot, my Linux kernel regression tracking bot
>> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
>> this mail to get things rolling again and hence don't need to be CC on
>> all further activities wrt to this regression.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"
2022-01-23 9:28 ` Thorsten Leemhuis
@ 2022-01-23 20:11 ` coldolt
0 siblings, 0 replies; 6+ messages in thread
From: coldolt @ 2022-01-23 20:11 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: An, Tedd, kai.heng.feng, marcel, linux-bluetooth, linux-kernel,
regressions
On Sun, Jan 23, 2022 at 11:28 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Top-posting for once, to make this easy accessible to everyone.
>
> Coldolt, could you please check if this regression is still in 5.17-rc1
> or 5.16.2? I wonder if this patch fixed things:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=8e8cae520210139aab4b701a822bbefb13b8f007
>
> Ciao, Thorsten
Yes, that commit fixes it for me. This same issue seems to have come
up many times in the past months, it is a duplicate of
#regzbot dup-of:
https://lore.kernel.org/lkml/b0f6f66b-28aa-9d43-0aab-e6887ee0fda8@logobject.ch/
#regzbot dup-of:
https://lore.kernel.org/lkml/20211202162256.31837-1-tiwai@suse.de/
#regzbot fixed-by: 95655456e7ce
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-23 20:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-09 23:36 [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue" coldolt
2021-12-10 1:10 ` An, Tedd
2021-12-10 9:16 ` Thorsten Leemhuis
2022-01-20 13:08 ` Thorsten Leemhuis
2022-01-23 9:28 ` Thorsten Leemhuis
2022-01-23 20:11 ` coldolt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).