On 23.5.2022. 10:41, Hrvoje Popovski wrote:
> On 23.5.2022. 8:34, Alexandr Nedvedicky wrote:
>> looks like kind of memory corruption. my bet is use-after-free.
>> will try to get to it later today.
>>
>> does it mean there is no such panic, when we handle IPv4 traffic only?
>
> Hi,
>
On 2022/05/23 16:24, Helmut Kiessling wrote:
> Hi Stuart,
>
> Usually it is however I tested 700, 755, root, ldap and yp service accounts
> for
> login_ldap.conf no luck unfortunately. I will test more when next to machine
> again. Anyway no
> biggie it works old way so I'm happy with it.
On 2022/05/23 15:39, helmut.kiessl...@btinternet.com wrote:
> Hi Stuart,
>
> Yes you were right and I was wrong. Login.conf is not automatically updated
> but my build script somehow skipped command 'cap_mkdb login.conf' and that
> was the main reason why authentication not worked. So all is good
Greetings,
I'm the person whom Matthias linked to. Seems as though we're having
the same issue with the touchpad in spite of them being different
laptops. I'm using the snapshot from Sunday, 22 May 2022, but previous
snapshots also had this issue. After some time, usually when using
Firefox, but
On 23.5.2022. 10:41, Hrvoje Popovski wrote:
> On 23.5.2022. 8:34, Alexandr Nedvedicky wrote:
>> looks like kind of memory corruption. my bet is use-after-free.
>> will try to get to it later today.
>>
>> does it mean there is no such panic, when we handle IPv4 traffic only?
>
> Hi,
>
On 23.5.2022. 8:34, Alexandr Nedvedicky wrote:
> looks like kind of memory corruption. my bet is use-after-free.
> will try to get to it later today.
>
> does it mean there is no such panic, when we handle IPv4 traffic only?
Hi,
yes, it seems that i can't trigger panic with ip4 only
>Synopsis: imt(4) Touchpad stalls from time to time
>Environment:
System : OpenBSD 7.1
Details : OpenBSD 7.1-current (GENERIC.MP) #533: Thu May 19
07:38:57 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Hello Hrvoje,
>
>
> ddb{3}> show panic
> *cpu3: pool_cache_item_magic_check: mbufpl cpu free list modified: item
> addr 0xfd80a41c3f00+24 0xaf551e6f8f90255f!=0xaf551e6f8f35fd5f
> cpu2: uvm_fault(0x823ba618, 0x17, 0, 2) -> e
> ddb{3}>
>
looks like kind of memory corruption.
