Note: The context was using a non-debug main build
from mid-2021-Mar. (More details identified
later.)
The issue happend while attempting a:
# zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
where the drives involved in the command were:
zpold: a USB3 SSD, using /dev/da0p3
zpnew: a
> What about adding a new flag to enable strtoul behavior?
I have had a look at the available flag options for a potential strtoul
flag, and a flag that makes sense to me is [-s] / [--strtoul]. [-s] is not
currently being used in i2c, if we wanted to use it.
On Fri, May 14, 2021 at 5:13 AM Rodney
Hi,
I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
(In particular, the sessions mechanism for "exactly once RPC semantics"
is a significant improvement over the duplicate request cache for NFSv4.0,
plu
> I have renovated the i2c(8) program and while I belive all argument
> processing is 100% compatible, various undocumented aspects of the
> program may have changed, amongst these precisely what goes to
> stdout and stderr.
>
> Apologies if this breaks any of your scripts.
>
>
> There is one
> On 12.05.2021 21:01, Marc Veldman wrote:
>
> > I?m not sure if this is an interesting data point or not,
> > but a warm boot without the card inserted succeeds after
> > a cold boot with the card inserted.
>
> It could explain, why my tests with "same code path" gave different results!
I am
On Thu, 13 May 2021 20:55:20 +0300
Lev Serebryakov wrote:
> On 13.05.2021 18:56, Henri Hennebert wrote:
>
> > So if I understand correctly, your problem is solved.
> Stupid me. I didn't check card insertion/removal after boot.
>
> Card REMOVAL when boot was WITH CARD:
> Instant panic:
>
On 13.05.2021 18:56, Henri Hennebert wrote:
So if I understand correctly, your problem is solved.
Stupid me. I didn't check card insertion/removal after boot.
Card REMOVAL when boot was WITH CARD:
Instant panic:
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
panic: mutex Giant no
> On 13 May 2021, at 17:56, Henri Hennebert wrote:
>
> On 5/13/21 5:51 PM, Lev Serebryakov wrote:
>> On 13.05.2021 18:38, Henri Hennebert via freebsd-current wrote:
>>> This seems a good news.
>>>
>>> Can you replace sys/dev/rtsx.c by the latest version (2.0g) from
>>> https://github.com/hlh-r
On 5/13/21 5:51 PM, Lev Serebryakov wrote:
On 13.05.2021 18:38, Henri Hennebert via freebsd-current wrote:
This seems a good news.
Can you replace sys/dev/rtsx.c by the latest version (2.0g) from
https://github.com/hlh-restart/rtsx
I reduce the DELAY to 25 and make some other updates wait
On 13.05.2021 18:38, Henri Hennebert via freebsd-current wrote:
This seems a good news.
Can you replace sys/dev/rtsx.c by the latest version (2.0g) from
https://github.com/hlh-restart/rtsx
I reduce the DELAY to 25 and make some other updates waiting in the
pipeline.
I've replaced two fil
On 5/13/21 5:09 PM, Lev Serebryakov wrote:
On 13.05.2021 17:22, Henri Hennebert wrote:
try to rebuild your kernel with the attached patch.
Nope, same panic after cold (power-cycle) boot.
Can you try with "DELAY(50);"
to see if this is a path to dig further.
It helps with panic!
On 2021-05-13 02:49, Henri Hennebert via freebsd-current wrote:
On 5/13/21 6:00 AM, Marc Veldman wrote:
On 12 May 2021, at 20:49, Henri Hennebert wrote:
On 5/12/21 8:01 PM, Marc Veldman wrote:
On 12 May 2021, at 18:06, Henri Hennebert wrote:
On 5/12/21 5:04 PM, Marc Veldman wrote:
Unfortu
On 13.05.2021 17:36, Toomas Soome wrote:
First thing, please check if you have boot1.efi or loader.efi in ESP (EFI
System Partition), and when it is loader.efi, please check it is latest.
loader.efi from Apr 15 2021
Then next step would be to test out gfx modes, on loader OK prompt, try to
On 13.05.2021 17:22, Henri Hennebert wrote:
try to rebuild your kernel with the attached patch.
Nope, same panic after cold (power-cycle) boot.
Can you try with "DELAY(50);"
to see if this is a path to dig further.
It helps with panic!
What do you mean? Does it display "card pres
> On 13. May 2021, at 17:04, Lev Serebryakov wrote:
>
>
> Is it possible to get native 1920x1080 resoultiuon and small fond (many
> lines) early on boot?
>
> Lenovo T540p has native resolution 1920x1080 and boots with UEFI. I've tried
> two configs:
>
> (1) No special configuration in /boo
On 5/13/21 4:18 PM, Lev Serebryakov wrote:
On 13.05.2021 16:40, Henri Hennebert wrote:
try to rebuild your kernel with the attached patch.
Nope, same panic after cold (power-cycle) boot.
Can you try with "DELAY(50);"
to see if this is a path to dig further.
It helps with panic!
On 13.05.2021 16:40, Henri Hennebert wrote:
try to rebuild your kernel with the attached patch.
Nope, same panic after cold (power-cycle) boot.
Can you try with "DELAY(50);"
to see if this is a path to dig further.
It helps with panic!
--
// Lev Serebryakov
Is it possible to get native 1920x1080 resoultiuon and small fond (many lines)
early on boot?
Lenovo T540p has native resolution 1920x1080 and boots with UEFI. I've tried
two configs:
(1) No special configuration in /boot/loader.conf
(1.1) Loader menu is ugly, font is large and jagged, loo
There was a recent discussion about a terminal database update and the
new Alternate Screen behavior. I'm curious about the resolution, but I
can't find that discussion. Would someone kindly send a clue-by-four
via overnight express?
Ultimately, I'd like to know how to get the old behavior b
On 5/13/21 3:30 PM, Lev Serebryakov wrote:
On 13.05.2021 15:48, Henri Hennebert via freebsd-current wrote:
rtsx0: <2.0c .>
rtsx0: Card present
mmc0: on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
...
This must be the culprit this change from present/absent
PANIC! (wi
On 13.05.2021 15:48, Henri Hennebert via freebsd-current wrote:
rtsx0: <2.0c .>
rtsx0: Card present
mmc0: on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
...
This must be the culprit this change from present/absent
PANIC! (without rtsx0 in stacktrace, again it is
run
On 5/13/21 2:40 PM, Lev Serebryakov wrote:
On 13.05.2021 15:13, Henri Hennebert via freebsd-current wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests
On 13.05.2021 15:13, Henri Hennebert via freebsd-current wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path" gave different results!
On 13.05.2021 15:06, Henri Hennebert via freebsd-current wrote:
Just what I was thinking: in this case the card status is found correctly
without an interrupt.
In the "cold" case an interrupt change the card present/absent status, a
taskqueue is scheduled. I am digging there...
It could ex
On 5/13/21 2:01 PM, Lev Serebryakov wrote:
On 13.05.2021 14:35, Henri Hennebert wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path"
I have renovated the i2c(8) program and while I belive all argument
processing is 100% compatible, various undocumented aspects of the
program may have changed, amongst these precisely what goes to
stdout and stderr.
Apologies if this breaks any of your scripts.
There is one aspect of this prog
On 5/13/21 1:58 PM, Marc Veldman wrote:
On 13 May 2021, at 11:49, Henri Hennebert wrote:
...
...
Do you see an rtsx message before this mmc0 ?
mmc0: detached
ugen0.1: <0x8086
Yes.
rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem 0xf410-0xf4100fff at
device 0.0 on pci1>
rtsx0
On 13.05.2021 14:35, Henri Hennebert wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path" gave different results!
With a "cold" boot
> On 13 May 2021, at 11:49, Henri Hennebert wrote:
>
...
...
>>> Do you see an rtsx message before this mmc0 ?
>>>
mmc0: detached
ugen0.1: <0x8086
>> Yes.
>> rtsx0: <2.0c Realtek RT5522A PCI MMC/SD Card reader mem
>> 0xf410-0xf4100fff at device 0.0 on pci1>
>> rtsx0: Card prese
On 5/13/21 1:31 PM, Lev Serebryakov wrote:
On 12.05.2021 21:01, Marc Veldman wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path" gav
On 12.05.2021 21:01, Marc Veldman wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path" gave different results!
--
// Lev Serebryakov
_
On 5/13/21 6:00 AM, Marc Veldman wrote:
On 12 May 2021, at 20:49, Henri Hennebert wrote:
On 5/12/21 8:01 PM, Marc Veldman wrote:
On 12 May 2021, at 18:06, Henri Hennebert wrote:
On 5/12/21 5:04 PM, Marc Veldman wrote:
Unfortunately I can only say “me too”, but on a different Lenovo laptop
32 matches
Mail list logo
