>> OK, so any requests >4K will have to be packaged into further range
>> requests [...]
> This isn't right. Bytes 7 & 8 of a TRIM range request form a
> counter. So, a counter of 1 = (1 x max_dsm_blocks); 2 = (2 x
> max_dsm_blocks) up to 0x counts.
So is max_dsm_blocks misnamed, or is it
>> I tried trimming 8 at 0. Still the same syndrome: TRIM timeout,
>> flush timeout, device timeout reading [...]
> You may have to set the AT_LBA48 flag (not sure if this is present on
> 5.2)
It is not. 5.2 has an ATA_LBA48 flag, going with the flags field of
struct ata_bio, but no LBA48 flag
On Fri, 9 Dec 2022, RVP wrote:
OK, so any requests >4K will have to be packaged into further range
requests [...]
This isn't right. Bytes 7 & 8 of a TRIM range request form a counter. So,
a counter of 1 = (1 x max_dsm_blocks); 2 = (2 x max_dsm_blocks) up to
0x counts. And you can have 64
On Sat, Dec 10, 2022 at 01:03:06 +0300, Valery Ushakov wrote:
> That causes breakpoints on a function entry to be misreported:
Actually it's more than that. The corresponding MD change in i386
db_frame_info that applies the same heuristic causes another side
effect.
With the heuristic I get
On Sat, Dec 10, 2022 at 01:03:06 +0300, Valery Ushakov wrote:
> KSYMS_RET? Then we can define separate DB_STGY_PROC (no heuristic)
> and DB_STGY_RET (with the heuristic).
>
> The downside is that all MD db_stack_trace_print functions need to be
> adjusted, but it actually makes sense to use
[ATTN: riastradh]
On Fri, Dec 09, 2022 at 02:59:12 +0300, Valery Ushakov wrote:
> [reposting from current-users]
>
> On Wed, Nov 30, 2022 at 13:05:52 +0300, Valery Ushakov wrote:
>
> > I tried to upgrade a 32-bit VBox VM from 9.99.99 to .107 and the
> > kernel from the yesterday's sources
On Fri, 9 Dec 2022, Mouse wrote:
What is the value of `max_dsm_blocks' that your drive reports?
Unfortunately, atactl(8) doesn't show this currently.
I added that - and the version numbers - to my printf.
atap_ata_major is 2040, 0x7f8.
atap_ata_minor is 283, 0x11b.
max_dsm_blocks is 8.
db_printsym has the following heuristic:
revision 1.68
date: 2021-12-13 04:25:29 +0300; author: chs; state: Exp; lines: +16 -2;
commitid: MT9cIBmUIZU1AqkD;
ddb: fix function names of "noreturn" functions in stack traces.
when looking up function names for stack traces (where the
BERTRAND Joël a écrit :
> Hello,
>
> If iscsi-9-current.diff provided by Michael van Elst seems to fix
> panic, it doesn't fix deadlock. Last night, when bacula was starting,
> system has stopped once again in this deadlock.
>
> No trace in log or console, and I cannot switch
>> Okay, that now seems unlikely. I tried to TRIM 32M at zero.
(Actually, 16M - 32K blocks is 16M.)
> What is the value of `max_dsm_blocks' that your drive reports?
> Unfortunately, atactl(8) doesn't show this currently.
I added that - and the version numbers - to my printf.
atap_ata_major is
I'm putting printf everywhere and I identified the struct acpi_resources res
variable is not valid condition to SIMPLEQ_FOREACH(ar, >ar_irq, ar_list)
in acpi_res_irq(). Trying to identify why.
In acpi_resource_parse() called by ihidev_intr_init() I see the if condition in
if (ops->init) is
On Thu, 8 Dec 2022, Mouse wrote:
Okay, that now seems unlikely. I tried to TRIM 32M at zero. (Much
more than that seems implausible, since the request has only 16 bits of
size, so the maximum representible size is 65535 blocks, or a smidgen
under 64M. And zero certainlky ought to be
12 matches
Mail list logo
