Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

вс, 17 окт. 2021 г. в 17:52, Pavel Timofeev :

>
>
> вс, 17 окт. 2021 г. в 11:19, Alexander Motin :
>
>> It may be a noise, but comparing logs I see in reboot case also
>> "acpi_ec0: not getting interrupts, switched to polled mode".  I am
>> thinking whether the problem may be caused not by SSD, but by some
>> resource conflict/misconfiguration in the system.  Pavel, can you
>> compare `devinfo -vr` and `lspci -v` in both cases. looking for any
>> differences?  Are you running the latest BIOS?
>>
>> On 12.10.2021 15:56, Warner Losh wrote:
>> > One piece of data that would be good to have:
>> >
>> > nvmecontrol identify nvme0
>> >
>> > There's an optional feature that none of my drives have, but that the
>> Linux
>> > driver does oddly
>> > weird things when enabled. The output of that command will help me
>> > understand if that may
>> > be in play. Maybe we need to do oddly weird things too :)
>> >
>> > Warner
>> >
>> > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh  wrote:
>> >
>> >>
>> >>
>> >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev 
>> wrote:
>> >>
>> >>> сб, 9 окт. 2021 г. в 14:59, Warner Losh :
>> >>>
>> >>>>
>> >>>>
>> >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev 
>> wrote:
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> пт, 8 окт. 2021 г. в 14:49, Warner Losh :
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev 
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> сб, 21 авг. 2021 г. в 15:22, Warner Losh :
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev > >
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>  Warner Losh :
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev <
>> tim...@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>>  Pavel Timofeev :
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Chuck Tuffli :
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev <
>> >>>>>>>>>>> tim...@gmail.com> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Hello
>> >>>>>>>>>>>>>> I've got a Dell Latitude 7400 and tried installing the
>> latest
>> >>>>>>>>>>>>> 14.0-CURRENT
>> >>>>>>>>>>>>>> (main-n248636-d20e9e02db3) on it.
>> >>>>>>>>>>>>>> Despite other things the weird one which concerns me is
>> >>>>>>>>>>>>>>   nvme0: Missing interrupt
>> >>>>>>>>>>>>>> message I get sometimes on the console.
>> >>>>>>>>>>>>>> It seems like I get it only after the reboot of the laptop,
>> >>>>>>>>>>> i. e. not
>> >>>>>>>>>>>>>> getting that message if I power cycle the laptop, at least
>> I
>> >>>>>>>>>>> haven't
>> >>>>>>>>>>>>> seen
>> >>>>>>>>>>>>>> them for now in such cases.
>> >>>>>>>>>>>>>> So when the laptop is rebooted I can't even take advantage
>> of
>> >>>>>>>>>&

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

вс, 17 окт. 2021 г. в 11:19, Alexander Motin :

> It may be a noise, but comparing logs I see in reboot case also
> "acpi_ec0: not getting interrupts, switched to polled mode".  I am
> thinking whether the problem may be caused not by SSD, but by some
> resource conflict/misconfiguration in the system.  Pavel, can you
> compare `devinfo -vr` and `lspci -v` in both cases. looking for any
> differences?  Are you running the latest BIOS?
>
> On 12.10.2021 15:56, Warner Losh wrote:
> > One piece of data that would be good to have:
> >
> > nvmecontrol identify nvme0
> >
> > There's an optional feature that none of my drives have, but that the
> Linux
> > driver does oddly
> > weird things when enabled. The output of that command will help me
> > understand if that may
> > be in play. Maybe we need to do oddly weird things too :)
> >
> > Warner
> >
> > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh  wrote:
> >
> >>
> >>
> >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev 
> wrote:
> >>
> >>> сб, 9 окт. 2021 г. в 14:59, Warner Losh :
> >>>
> >>>>
> >>>>
> >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev  wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> пт, 8 окт. 2021 г. в 14:49, Warner Losh :
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev 
> >>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> сб, 21 авг. 2021 г. в 15:22, Warner Losh :
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev 
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  Warner Losh :
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev <
> tim...@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>  Pavel Timofeev :
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Chuck Tuffli :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev <
> >>>>>>>>>>> tim...@gmail.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hello
> >>>>>>>>>>>>>> I've got a Dell Latitude 7400 and tried installing the
> latest
> >>>>>>>>>>>>> 14.0-CURRENT
> >>>>>>>>>>>>>> (main-n248636-d20e9e02db3) on it.
> >>>>>>>>>>>>>> Despite other things the weird one which concerns me is
> >>>>>>>>>>>>>>   nvme0: Missing interrupt
> >>>>>>>>>>>>>> message I get sometimes on the console.
> >>>>>>>>>>>>>> It seems like I get it only after the reboot of the laptop,
> >>>>>>>>>>> i. e. not
> >>>>>>>>>>>>>> getting that message if I power cycle the laptop, at least I
> >>>>>>>>>>> haven't
> >>>>>>>>>>>>> seen
> >>>>>>>>>>>>>> them for now in such cases.
> >>>>>>>>>>>>>> So when the laptop is rebooted I can't even take advantage
> of
> >>>>>>>>>>>>>> nvmecontrol(8) quickly.
> >>>>>>>>>>>>>> Well, it still works, but it takes tens of seconds to return
> >>>>>>>>>>> the output.
> >>>>>>>>>>>>> ...
> >>>>>>>>>>>>>> dmesg when power cycled -
> >>>>>>>>>>>>>>
>

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

вт, 12 окт. 2021 г. в 13:56, Warner Losh :

> One piece of data that would be good to have:
>
> nvmecontrol identify nvme0
>
> There's an optional feature that none of my drives have, but that the
> Linux driver does oddly
> weird things when enabled. The output of that command will help me
> understand if that may
> be in play. Maybe we need to do oddly weird things too :)
>
> Warner
>
> On Sun, Oct 10, 2021 at 11:00 PM Warner Losh  wrote:
>
>>
>>
>> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev  wrote:
>>
>>> сб, 9 окт. 2021 г. в 14:59, Warner Losh :
>>>
>>>>
>>>>
>>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev  wrote:
>>>>
>>>>>
>>>>>
>>>>> пт, 8 окт. 2021 г. в 14:49, Warner Losh :
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> сб, 21 авг. 2021 г. в 15:22, Warner Losh :
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Warner Losh :
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>  Pavel Timofeev :
>>>>>>>>>>>
>>>>>>>>>>> >
>>>>>>>>>>> > Chuck Tuffli :
>>>>>>>>>>> >
>>>>>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev <
>>>>>>>>>>> tim...@gmail.com> wrote:
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > Hello
>>>>>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the
>>>>>>>>>>> latest
>>>>>>>>>>> >> 14.0-CURRENT
>>>>>>>>>>> >> > (main-n248636-d20e9e02db3) on it.
>>>>>>>>>>> >> > Despite other things the weird one which concerns me is
>>>>>>>>>>> >> >   nvme0: Missing interrupt
>>>>>>>>>>> >> > message I get sometimes on the console.
>>>>>>>>>>> >> > It seems like I get it only after the reboot of the laptop,
>>>>>>>>>>> i. e. not
>>>>>>>>>>> >> > getting that message if I power cycle the laptop, at least
>>>>>>>>>>> I haven't
>>>>>>>>>>> >> seen
>>>>>>>>>>> >> > them for now in such cases.
>>>>>>>>>>> >> > So when the laptop is rebooted I can't even take advantage
>>>>>>>>>>> of
>>>>>>>>>>> >> > nvmecontrol(8) quickly.
>>>>>>>>>>> >> > Well, it still works, but it takes tens of seconds to
>>>>>>>>>>> return the output.
>>>>>>>>>>> >> ...
>>>>>>>>>>> >> > dmesg when power cycled -
>>>>>>>>>>> >> >
>>>>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ
>>>>>>>>>>> >> > dmesg when rebooted -
>>>>>>>>>>> >> >
>>>>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh
>>>>>>>>>>> >>
>>>>>>>>>>> >> I'm sort of curious about the time stamps for the log
>>>>>>>>>>> messages in the
>>>>>>>>>>> >> failing case. Something like:
>>>>>>>>>>> >>
>>>>>>>>>>> >> $ grep "nv\(m

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

сб, 9 окт. 2021 г. в 14:59, Warner Losh :

>
>
> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev  wrote:
>
>>
>>
>> пт, 8 окт. 2021 г. в 14:49, Warner Losh :
>>
>>>
>>>
>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev  wrote:
>>>
>>>>
>>>>
>>>> сб, 21 авг. 2021 г. в 15:22, Warner Losh :
>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>  Warner Losh :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>  Pavel Timofeev :
>>>>>>>>
>>>>>>>> >
>>>>>>>> > Chuck Tuffli :
>>>>>>>> >
>>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev 
>>>>>>>> wrote:
>>>>>>>> >> >
>>>>>>>> >> > Hello
>>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest
>>>>>>>> >> 14.0-CURRENT
>>>>>>>> >> > (main-n248636-d20e9e02db3) on it.
>>>>>>>> >> > Despite other things the weird one which concerns me is
>>>>>>>> >> >   nvme0: Missing interrupt
>>>>>>>> >> > message I get sometimes on the console.
>>>>>>>> >> > It seems like I get it only after the reboot of the laptop, i.
>>>>>>>> e. not
>>>>>>>> >> > getting that message if I power cycle the laptop, at least I
>>>>>>>> haven't
>>>>>>>> >> seen
>>>>>>>> >> > them for now in such cases.
>>>>>>>> >> > So when the laptop is rebooted I can't even take advantage of
>>>>>>>> >> > nvmecontrol(8) quickly.
>>>>>>>> >> > Well, it still works, but it takes tens of seconds to return
>>>>>>>> the output.
>>>>>>>> >> ...
>>>>>>>> >> > dmesg when power cycled -
>>>>>>>> >> >
>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ
>>>>>>>> >> > dmesg when rebooted -
>>>>>>>> >> >
>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh
>>>>>>>> >>
>>>>>>>> >> I'm sort of curious about the time stamps for the log messages
>>>>>>>> in the
>>>>>>>> >> failing case. Something like:
>>>>>>>> >>
>>>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages
>>>>>>>> >>
>>>>>>>> >> --chuck
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I
>>>>>>>> missing some
>>>>>>>> > configuration for that?
>>>>>>>> >
>>>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages
>>>>>>>> > nvme0:  mem
>>>>>>>> > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff
>>>>>>>> at device
>>>>>>>> > 0.0 on pci6
>>>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported)
>>>>>>>> > nvme0: using IRQs 133-137 for MSI-X
>>>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20
>>>>>>>> > nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX
>>>>>>>> 0
>>>>>>>> > nvme0: Version: 0x00010300: 1.3
>>>>>>>> > nvme0: Missing interrupt
>>>>>>>> > nvme0: Missing interrupt
>>>>>>>> > nvme0: Missing interrupt
>>>>>>>> > nvme0: Missing interrupt
>>>>>>>> > nvme0: Missing interrupt
&g

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

пт, 8 окт. 2021 г. в 14:49, Warner Losh :

>
>
> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev  wrote:
>
>>
>>
>> сб, 21 авг. 2021 г. в 15:22, Warner Losh :
>>
>>>
>>>
>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev  wrote:
>>>
>>>>
>>>>
>>>>  Warner Losh :
>>>>
>>>>>
>>>>>
>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev 
>>>>> wrote:
>>>>>
>>>>>>  Pavel Timofeev :
>>>>>>
>>>>>> >
>>>>>> > Chuck Tuffli :
>>>>>> >
>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev 
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> > Hello
>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest
>>>>>> >> 14.0-CURRENT
>>>>>> >> > (main-n248636-d20e9e02db3) on it.
>>>>>> >> > Despite other things the weird one which concerns me is
>>>>>> >> >   nvme0: Missing interrupt
>>>>>> >> > message I get sometimes on the console.
>>>>>> >> > It seems like I get it only after the reboot of the laptop, i.
>>>>>> e. not
>>>>>> >> > getting that message if I power cycle the laptop, at least I
>>>>>> haven't
>>>>>> >> seen
>>>>>> >> > them for now in such cases.
>>>>>> >> > So when the laptop is rebooted I can't even take advantage of
>>>>>> >> > nvmecontrol(8) quickly.
>>>>>> >> > Well, it still works, but it takes tens of seconds to return the
>>>>>> output.
>>>>>> >> ...
>>>>>> >> > dmesg when power cycled -
>>>>>> >> >
>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ
>>>>>> >> > dmesg when rebooted -
>>>>>> >> >
>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh
>>>>>> >>
>>>>>> >> I'm sort of curious about the time stamps for the log messages in
>>>>>> the
>>>>>> >> failing case. Something like:
>>>>>> >>
>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages
>>>>>> >>
>>>>>> >> --chuck
>>>>>> >>
>>>>>> >
>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I missing
>>>>>> some
>>>>>> > configuration for that?
>>>>>> >
>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages
>>>>>> > nvme0:  mem
>>>>>> > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff
>>>>>> at device
>>>>>> > 0.0 on pci6
>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported)
>>>>>> > nvme0: using IRQs 133-137 for MSI-X
>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20
>>>>>> > nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0
>>>>>> > nvme0: Version: 0x00010300: 1.3
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvme0: Missing interrupt
>>>>>> > nvd0:  NVMe namespace
>>>>>> > GEOM: new disk nvd0
>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors)
>>>>>> >
>>>>>>
>>>>>>
>>>>>> Ah, sorry, provided wrong output.
>>>>>> Here is what you requested:
>>>>>> $ grep "nv\(me\|d\)" /var/log/messages
>>>>>> Aug 2

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

сб, 21 авг. 2021 г. в 15:22, Warner Losh :

>
>
> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev  wrote:
>
>>
>>
>>  Warner Losh :
>>
>>>
>>>
>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev 
>>> wrote:
>>>
>>>>  Pavel Timofeev :
>>>>
>>>> >
>>>> > Chuck Tuffli :
>>>> >
>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev 
>>>> wrote:
>>>> >> >
>>>> >> > Hello
>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest
>>>> >> 14.0-CURRENT
>>>> >> > (main-n248636-d20e9e02db3) on it.
>>>> >> > Despite other things the weird one which concerns me is
>>>> >> >   nvme0: Missing interrupt
>>>> >> > message I get sometimes on the console.
>>>> >> > It seems like I get it only after the reboot of the laptop, i. e.
>>>> not
>>>> >> > getting that message if I power cycle the laptop, at least I
>>>> haven't
>>>> >> seen
>>>> >> > them for now in such cases.
>>>> >> > So when the laptop is rebooted I can't even take advantage of
>>>> >> > nvmecontrol(8) quickly.
>>>> >> > Well, it still works, but it takes tens of seconds to return the
>>>> output.
>>>> >> ...
>>>> >> > dmesg when power cycled -
>>>> >> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ
>>>> >> > dmesg when rebooted -
>>>> >> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh
>>>> >>
>>>> >> I'm sort of curious about the time stamps for the log messages in the
>>>> >> failing case. Something like:
>>>> >>
>>>> >> $ grep "nv\(me\|d\)" /var/log/messages
>>>> >>
>>>> >> --chuck
>>>> >>
>>>> >
>>>> > Well, I can't see timestamps in the verbose boot log. Am I missing
>>>> some
>>>> > configuration for that?
>>>> >
>>>> > $ grep "nv\(me\|d\)" /var/log/messages
>>>> > nvme0:  mem
>>>> > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>>>> device
>>>> > 0.0 on pci6
>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported)
>>>> > nvme0: using IRQs 133-137 for MSI-X
>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20
>>>> > nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0
>>>> > nvme0: Version: 0x00010300: 1.3
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvme0: Missing interrupt
>>>> > nvd0:  NVMe namespace
>>>> > GEOM: new disk nvd0
>>>> > nvd0: 488386MB (1000215216 512 byte sectors)
>>>> >
>>>>
>>>>
>>>> Ah, sorry, provided wrong output.
>>>> Here is what you requested:
>>>> $ grep "nv\(me\|d\)" /var/log/messages
>>>> Aug 21 04:34:36 nostromo kernel: nvme0:  mem
>>>> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>>>> device
>>>> 0.0 on pci6
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI-X
>>>> vectors (17 supported)
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023,
>>>> CQR,
>>>> TO 20
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x0030: DSTRD 0,
>>>> NSSRS,
>>>> CSS 1, MPSMIN 0, MPSMAX 0
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
>>>> Aug 21 04

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

 Warner Losh :

>
>
> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev  wrote:
>
>>  Pavel Timofeev :
>>
>> >
>> > Chuck Tuffli :
>> >
>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev 
>> wrote:
>> >> >
>> >> > Hello
>> >> > I've got a Dell Latitude 7400 and tried installing the latest
>> >> 14.0-CURRENT
>> >> > (main-n248636-d20e9e02db3) on it.
>> >> > Despite other things the weird one which concerns me is
>> >> >   nvme0: Missing interrupt
>> >> > message I get sometimes on the console.
>> >> > It seems like I get it only after the reboot of the laptop, i. e. not
>> >> > getting that message if I power cycle the laptop, at least I haven't
>> >> seen
>> >> > them for now in such cases.
>> >> > So when the laptop is rebooted I can't even take advantage of
>> >> > nvmecontrol(8) quickly.
>> >> > Well, it still works, but it takes tens of seconds to return the
>> output.
>> >> ...
>> >> > dmesg when power cycled -
>> >> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ
>> >> > dmesg when rebooted -
>> >> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh
>> >>
>> >> I'm sort of curious about the time stamps for the log messages in the
>> >> failing case. Something like:
>> >>
>> >> $ grep "nv\(me\|d\)" /var/log/messages
>> >>
>> >> --chuck
>> >>
>> >
>> > Well, I can't see timestamps in the verbose boot log. Am I missing some
>> > configuration for that?
>> >
>> > $ grep "nv\(me\|d\)" /var/log/messages
>> > nvme0:  mem
>> > 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>> device
>> > 0.0 on pci6
>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported)
>> > nvme0: using IRQs 133-137 for MSI-X
>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20
>> > nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0
>> > nvme0: Version: 0x00010300: 1.3
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvme0: Missing interrupt
>> > nvd0:  NVMe namespace
>> > GEOM: new disk nvd0
>> > nvd0: 488386MB (1000215216 512 byte sectors)
>> >
>>
>>
>> Ah, sorry, provided wrong output.
>> Here is what you requested:
>> $ grep "nv\(me\|d\)" /var/log/messages
>> Aug 21 04:34:36 nostromo kernel: nvme0:  mem
>> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at
>> device
>> 0.0 on pci6
>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI-X
>> vectors (17 supported)
>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X
>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023, CQR,
>> TO 20
>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x0030: DSTRD 0, NSSRS,
>> CSS 1, MPSMIN 0, MPSMAX 0
>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3
>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
>> Aug 21 04:34:36 nostromo kernel: nvd0:  NVMe
>> namespace
>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0
>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byte
>> sectors)
>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt
>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt
>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt
>>
>
> What happens if you set hw.nvme.use_nvd=0 and hw.cam.nda.nvd_compat=1
> in the boot loader and reboot? Same thing except nda where nvd was? Or does
> it work?
>
> Something weird is going on in the interrupt assignment, I think, but I
> wanted to get any nvd vs nda issues out of the way first.
>
> Warner
>

Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compat?
kern.cam.nda.nvd_compat is 1 by default now.

So I tried to set  hw.nvme.use_nvd to 1 as suggested, but I still see
  nvme0: Missing interrupt
and now also
  Root mount waiting for: CAM
messages besides those

Re: Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

 Pavel Timofeev :

>
> Chuck Tuffli :
>
>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev  wrote:
>> >
>> > Hello
>> > I've got a Dell Latitude 7400 and tried installing the latest
>> 14.0-CURRENT
>> > (main-n248636-d20e9e02db3) on it.
>> > Despite other things the weird one which concerns me is
>> >   nvme0: Missing interrupt
>> > message I get sometimes on the console.
>> > It seems like I get it only after the reboot of the laptop, i. e. not
>> > getting that message if I power cycle the laptop, at least I haven't
>> seen
>> > them for now in such cases.
>> > So when the laptop is rebooted I can't even take advantage of
>> > nvmecontrol(8) quickly.
>> > Well, it still works, but it takes tens of seconds to return the output.
>> ...
>> > dmesg when power cycled -
>> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ
>> > dmesg when rebooted -
>> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh
>>
>> I'm sort of curious about the time stamps for the log messages in the
>> failing case. Something like:
>>
>> $ grep "nv\(me\|d\)" /var/log/messages
>>
>> --chuck
>>
>
> Well, I can't see timestamps in the verbose boot log. Am I missing some
> configuration for that?
>
> $ grep "nv\(me\|d\)" /var/log/messages
> nvme0:  mem
> 0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device
> 0.0 on pci6
> nvme0: attempting to allocate 5 MSI-X vectors (17 supported)
> nvme0: using IRQs 133-137 for MSI-X
> nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20
> nvme0: CapHi: 0x0030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0
> nvme0: Version: 0x00010300: 1.3
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvme0: Missing interrupt
> nvd0:  NVMe namespace
> GEOM: new disk nvd0
> nvd0: 488386MB (1000215216 512 byte sectors)
>


Ah, sorry, provided wrong output.
Here is what you requested:
$ grep "nv\(me\|d\)" /var/log/messages
Aug 21 04:34:36 nostromo kernel: nvme0:  mem
0xcc10-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device
0.0 on pci6
Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI-X
vectors (17 supported)
Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X
Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023, CQR,
TO 20
Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x0030: DSTRD 0, NSSRS,
CSS 1, MPSMIN 0, MPSMAX 0
Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3
Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt
Aug 21 04:34:36 nostromo kernel: nvd0:  NVMe
namespace
Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0
Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byte
sectors)
Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt
Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt
Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt

Dell Latitude 7400 - nvme0: Missing interrupt

[Pavel Timofeev]

Hello
I've got a Dell Latitude 7400 and tried installing the latest 14.0-CURRENT
(main-n248636-d20e9e02db3) on it.
Despite other things the weird one which concerns me is
  nvme0: Missing interrupt
message I get sometimes on the console.
It seems like I get it only after the reboot of the laptop, i. e. not
getting that message if I power cycle the laptop, at least I haven't seen
them for now in such cases.
So when the laptop is rebooted I can't even take advantage of
nvmecontrol(8) quickly.
Well, it still works, but it takes tens of seconds to return the output.


# pciconf -lv
hostb0@pci0:0:0:0: class=0x06 rev=0x0c hdr=0x00 vendor=0x8086
device=0x3e34 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Coffee Lake HOST and DRAM Controller'
class  = bridge
subclass   = HOST-PCI
vgapci0@pci0:0:2:0: class=0x03 rev=0x02 hdr=0x00 vendor=0x8086
device=0x3ea0 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'WhiskeyLake-U GT2 [UHD Graphics 620]'
class  = display
subclass   = VGA
none0@pci0:0:4:0: class=0x118000 rev=0x0c hdr=0x00 vendor=0x8086
device=0x1903 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal
Subsystem'
class  = dasp
none1@pci0:0:8:0: class=0x088000 rev=0x00 hdr=0x00 vendor=0x8086
device=0x1911 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core
Processor Gaussian Mixture Model'
class  = base peripheral
pchtherm0@pci0:0:18:0: class=0x118000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9df9 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Thermal Controller'
class  = dasp
none2@pci0:0:19:0: class=0x07 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9dfc subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Integrated Sensor Hub'
class  = simple comms
subclass   = UART
xhci0@pci0:0:20:0: class=0x0c0330 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9ded subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP USB 3.1 xHCI Controller'
class  = serial bus
subclass   = USB
none3@pci0:0:20:2: class=0x05 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9def subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Shared SRAM'
class  = memory
subclass   = RAM
iwm0@pci0:0:20:3: class=0x028000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9df0 subvendor=0x8086 subdevice=0x4030
vendor = 'Intel Corporation'
device = 'Cannon Point-LP CNVi [Wireless-AC]'
class  = network
ig4iic0@pci0:0:21:0: class=0x0c8000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9de8 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Serial IO I2C Controller'
class  = serial bus
ig4iic1@pci0:0:21:1: class=0x0c8000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9de9 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Serial IO I2C Controller'
class  = serial bus
ig4iic2@pci0:0:21:3: class=0x0c8000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9deb subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
class  = serial bus
none4@pci0:0:22:0: class=0x078000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9de0 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP MEI Controller'
class  = simple comms
ig4iic3@pci0:0:25:0: class=0x0c8000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9dc5 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Serial IO I2C Host Controller'
class  = serial bus
pcib1@pci0:0:28:0: class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9dbc subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:29:0: class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9db3 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
class  = bridge
subclass   = PCI-PCI
pcib7@pci0:0:29:4: class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9db4 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0: class=0x060100 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9d84 subvendor=0x1028 subdevice=0x08e1
vendor = 'Intel Corporation'
device = 'Cannon Point-LP LPC Controller'
class  = bridge
subclass   = PCI-ISA
hdac0@pci0:0:31:3: 

bhyve(8) missing new feature description about netgraph integration

[Pavel Timofeev]

Hi,
I saw this nice change in svn - "Add a new bhyve network backend that allow
to connect the VM to the netgraph(4) network"
https://svnweb.freebsd.org/base?view=revision=360958

Does anybody know if there is any prepared but not-committed yet review or
something to reflect this change in bhyve(8) man page?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT: if_bridge performance improvements

[Pavel Timofeev]

вт, 14 апр. 2020 г., 12:51 Kristof Provost :

> Hi,
>
> Thanks to support from The FreeBSD Foundation I’ve been able to work
> on improving the throughput of if_bridge.
> It changes the (data path) locking to use the NET_EPOCH infrastructure.
> Benchmarking shows substantial improvements (x5 in test setups).
>
> This work is ready for wider testing now.
>
> It’s under review here: https://reviews.freebsd.org/D24250
>
> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
> Patches for stable/12:
> https://people.freebsd.org/~kp/if_bridge/stable_12/
>
> I’m not currently aware of any panics or issues resulting from these
> patches.
>
> Do note that if you run a Bhyve + tap on bridges setup the tap code
> suffers from a similar bottleneck and you will likely not see major
> improvements in single VM to host throughput. I would expect, but have
> not tested, improvements in overall throughput (i.e. when multiple VMs
> send traffic at the same time).
>
> Best regards,
> Kristof
>

Hi!
Thank you for your work!
Do you know if epair suffers from the same issue as tap?

>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Can't cross-compile HEAD

[Pavel Timofeev]

пт, 10 янв. 2020 г. в 22:05, Kyle Evans :
>
> On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev  wrote:
> >
> > пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> > >
> > > On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev  wrote:
> > > >
> > > > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > > > >
> > > > > Hello
> > > > >
> > > > > I'm trying to cross-compile HEAD r356551 for mips on my FreeBSD-12.1 
> > > > > amd64.
> > > > > I'm using mips-gcc6-6.5.0 and this
> > > > > https://github.com/freebsd/freebsd-wifi-build nice project to build
> > > > > image for my tl-wdr3600
> > > > >
> > > > > The error I'm getting is:
> > > > > ...
> > > > > ===> usr.sbin/fmtree (all)
> > > > > ===> usr.bin/vi (all)
> > > > > ===> usr.sbin/freebsd-update (all)
> > > > > ===> usr.sbin/gpioctl (all)
> > > > > ===> usr.sbin/inetd (all)
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function
> > > > > 'getconfigent':
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
> > > > > warning: variable 'v4bind' set but not used
> > > > > [-Wunused-but-set-variable]
> > > > >   int v4bind;
> > > > >   ^~
> > > > > At top level:
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
> > > > > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> > > > >  static const char copyright[] =
> > > > >^
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In 
> > > > > function 'setup':
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
> > > > > error: 'netid' may be used uninitialized in this function
> > > > > [-Werror=maybe-uninitialized]
> > > > > rpcb_set(sep->se_rpc_prog, i, netid, );
> > > > > ^~~
> > > > > cc1: all warnings being treated as errors
> > > > > --- inetd.o ---
> > > > > *** [inetd.o] Error code 1
> > > > >
> > > > >
> > > > > Could anybody please help fix that?
> > > >
> > > >
> > > >
> > > > Terribly sorry, I forgot to mention a very important detail.
> > > > My src.conf has the only option now.
> > > > It's WITHOUT_INET6="YES"
> > >
> > > Thanks for that addition- you saved me a little bit of effort
> > > examining why it's unused. =-)
> > >
> > > The inetd build should be clear after r356602, but you'll need to
> > > build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
> > > some fundamental issues with mips-gcc{6,9} trying to emit
> > > __floatunsidf references, but that's a hidden symbol in our libgcc.
> > >
> > > I expect to, by the end of the day, either have a fix pending or mark
> > > it as a BROKEN_OPTION on mips+gcc while we hash out the details , as
> > > gcc{6,9} is the only option we support for building mips at the
> > > moment.
> > >
> > > Thanks,
> > >
> > > Kyle Evans
> >
> > Thanks a lot, Kyle!
> > Build process passes further!
> > Now I'm on r356606 and have these in src.conf
> > WITHOUT_GOOGLETEST=yes
> > WITHOUT_INET6="YES"
> >
> > Getting different error:
> > 
>
> I'm re-running the build WITHOUT_GOOGLETEST here outside of a
> freebsd-wifi-build context, but CC'ing Adrian in case he's already
> familiar since he's been battling libarchive stuff recently. Leaving
> the context below intact in case he's not received this.


Hi,
Ok, seems like I found how to fix that particular libarchive/zstd
issue. It happened during bsdbox build proccess BTW.
So here is what I did:

$ svn diff head/tools/bsdbox
Index: head/tools/bsdbox/Makefile.base
===
--- head/tools/bsdbox/Makefile.base (revision 358209)
+++ head/tools/bsdbox/Makefile.base (working copy)
@@ -19,7 +19,7 @@
 # CRUNCH_PROGS_usr.bin+=   tar
 CRUNCH_PROGS_usr.bin+= cpio
 # XXX SSL ?
-CRUNCH_LIBS+=  -larchive -lbz2 -lz -llzma -lbsdxml -lssl -lcrypto
+CRUNCH_LIBS+=  -larchive -lbz2 -lz -llzma -lbsdxml -lssl
-lcrypto -lprivatezstd -lthr

 # Clear requires 

Re: Can't cross-compile HEAD

[Pavel Timofeev]

сб, 11 янв. 2020 г. в 08:06, Pavel Timofeev :
>
> пт, 10 янв. 2020 г. в 22:05, Kyle Evans :
> >
> > On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev  wrote:
> > >
> > > пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> > > >
> > > > On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev  
> > > > wrote:
> > > > >
> > > > > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > > > > >
> > > > > > Hello
> > > > > >
> > > > > > I'm trying to cross-compile HEAD r356551 for mips on my 
> > > > > > FreeBSD-12.1 amd64.
> > > > > > I'm using mips-gcc6-6.5.0 and this
> > > > > > https://github.com/freebsd/freebsd-wifi-build nice project to build
> > > > > > image for my tl-wdr3600
> > > > > >
> > > > > > The error I'm getting is:
> > > > > > ...
> > > > > > ===> usr.sbin/fmtree (all)
> > > > > > ===> usr.bin/vi (all)
> > > > > > ===> usr.sbin/freebsd-update (all)
> > > > > > ===> usr.sbin/gpioctl (all)
> > > > > > ===> usr.sbin/inetd (all)
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In 
> > > > > > function
> > > > > > 'getconfigent':
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
> > > > > > warning: variable 'v4bind' set but not used
> > > > > > [-Wunused-but-set-variable]
> > > > > >   int v4bind;
> > > > > >   ^~
> > > > > > At top level:
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
> > > > > > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> > > > > >  static const char copyright[] =
> > > > > >^
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In 
> > > > > > function 'setup':
> > > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
> > > > > > error: 'netid' may be used uninitialized in this function
> > > > > > [-Werror=maybe-uninitialized]
> > > > > > rpcb_set(sep->se_rpc_prog, i, netid, );
> > > > > > ^~~
> > > > > > cc1: all warnings being treated as errors
> > > > > > --- inetd.o ---
> > > > > > *** [inetd.o] Error code 1
> > > > > >
> > > > > >
> > > > > > Could anybody please help fix that?
> > > > >
> > > > >
> > > > >
> > > > > Terribly sorry, I forgot to mention a very important detail.
> > > > > My src.conf has the only option now.
> > > > > It's WITHOUT_INET6="YES"
> > > >
> > > > Thanks for that addition- you saved me a little bit of effort
> > > > examining why it's unused. =-)
> > > >
> > > > The inetd build should be clear after r356602, but you'll need to
> > > > build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
> > > > some fundamental issues with mips-gcc{6,9} trying to emit
> > > > __floatunsidf references, but that's a hidden symbol in our libgcc.
> > > >
> > > > I expect to, by the end of the day, either have a fix pending or mark
> > > > it as a BROKEN_OPTION on mips+gcc while we hash out the details , as
> > > > gcc{6,9} is the only option we support for building mips at the
> > > > moment.
> > > >
> > > > Thanks,
> > > >
> > > > Kyle Evans
> > >
> > > Thanks a lot, Kyle!
> > > Build process passes further!
> > > Now I'm on r356606 and have these in src.conf
> > > WITHOUT_GOOGLETEST=yes
> > > WITHOUT_INET6="YES"
> > >
> > > Getting different error:
> > > 
> >
> > I'm re-running the build WITHOUT_GOOGLETEST here outside of a
> > freebsd-wifi-build context, but CC'ing Adrian in case he's already
> > familiar since he's been battling libarchive stuff recently. Leaving
> > the context below intact in case he's not received this.
> >
> > > ===> usr.sbin/sendmail (all)
> > > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:33:19:
> > &g

Re: Can't cross-compile HEAD

[Pavel Timofeev]

пт, 10 янв. 2020 г. в 22:05, Kyle Evans :
>
> On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev  wrote:
> >
> > пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> > >
> > > On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev  wrote:
> > > >
> > > > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > > > >
> > > > > Hello
> > > > >
> > > > > I'm trying to cross-compile HEAD r356551 for mips on my FreeBSD-12.1 
> > > > > amd64.
> > > > > I'm using mips-gcc6-6.5.0 and this
> > > > > https://github.com/freebsd/freebsd-wifi-build nice project to build
> > > > > image for my tl-wdr3600
> > > > >
> > > > > The error I'm getting is:
> > > > > ...
> > > > > ===> usr.sbin/fmtree (all)
> > > > > ===> usr.bin/vi (all)
> > > > > ===> usr.sbin/freebsd-update (all)
> > > > > ===> usr.sbin/gpioctl (all)
> > > > > ===> usr.sbin/inetd (all)
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function
> > > > > 'getconfigent':
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
> > > > > warning: variable 'v4bind' set but not used
> > > > > [-Wunused-but-set-variable]
> > > > >   int v4bind;
> > > > >   ^~
> > > > > At top level:
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
> > > > > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> > > > >  static const char copyright[] =
> > > > >^
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In 
> > > > > function 'setup':
> > > > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
> > > > > error: 'netid' may be used uninitialized in this function
> > > > > [-Werror=maybe-uninitialized]
> > > > > rpcb_set(sep->se_rpc_prog, i, netid, );
> > > > > ^~~
> > > > > cc1: all warnings being treated as errors
> > > > > --- inetd.o ---
> > > > > *** [inetd.o] Error code 1
> > > > >
> > > > >
> > > > > Could anybody please help fix that?
> > > >
> > > >
> > > >
> > > > Terribly sorry, I forgot to mention a very important detail.
> > > > My src.conf has the only option now.
> > > > It's WITHOUT_INET6="YES"
> > >
> > > Thanks for that addition- you saved me a little bit of effort
> > > examining why it's unused. =-)
> > >
> > > The inetd build should be clear after r356602, but you'll need to
> > > build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
> > > some fundamental issues with mips-gcc{6,9} trying to emit
> > > __floatunsidf references, but that's a hidden symbol in our libgcc.
> > >
> > > I expect to, by the end of the day, either have a fix pending or mark
> > > it as a BROKEN_OPTION on mips+gcc while we hash out the details , as
> > > gcc{6,9} is the only option we support for building mips at the
> > > moment.
> > >
> > > Thanks,
> > >
> > > Kyle Evans
> >
> > Thanks a lot, Kyle!
> > Build process passes further!
> > Now I'm on r356606 and have these in src.conf
> > WITHOUT_GOOGLETEST=yes
> > WITHOUT_INET6="YES"
> >
> > Getting different error:
> > 
>
> I'm re-running the build WITHOUT_GOOGLETEST here outside of a
> freebsd-wifi-build context, but CC'ing Adrian in case he's already
> familiar since he's been battling libarchive stuff recently. Leaving
> the context below intact in case he's not received this.
>
> > ===> usr.sbin/sendmail (all)
> > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:33:19:
> > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> >  static const char copyright[] =
> >^
> > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c: In function
> > 'getname':
> > /usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:520:6:
> > warning: variable 'ppp_state' might be clobbered by 'longjmp' or
> > 'vfork' [-Wclobbered]
> >   int ppp_state = 0;
> >   ^
> > /usr/home/pavel.timofeev/mips/head/libexec/getty

Re: Can't cross-compile HEAD

[Pavel Timofeev]

пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
>
> On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev  wrote:
> >
> > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > >
> > > Hello
> > >
> > > I'm trying to cross-compile HEAD r356551 for mips on my FreeBSD-12.1 
> > > amd64.
> > > I'm using mips-gcc6-6.5.0 and this
> > > https://github.com/freebsd/freebsd-wifi-build nice project to build
> > > image for my tl-wdr3600
> > >
> > > The error I'm getting is:
> > > ...
> > > ===> usr.sbin/fmtree (all)
> > > ===> usr.bin/vi (all)
> > > ===> usr.sbin/freebsd-update (all)
> > > ===> usr.sbin/gpioctl (all)
> > > ===> usr.sbin/inetd (all)
> > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function
> > > 'getconfigent':
> > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
> > > warning: variable 'v4bind' set but not used
> > > [-Wunused-but-set-variable]
> > >   int v4bind;
> > >   ^~
> > > At top level:
> > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
> > > warning: 'copyright' defined but not used [-Wunused-const-variable=]
> > >  static const char copyright[] =
> > >^
> > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function 
> > > 'setup':
> > > /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
> > > error: 'netid' may be used uninitialized in this function
> > > [-Werror=maybe-uninitialized]
> > > rpcb_set(sep->se_rpc_prog, i, netid, );
> > > ^~~
> > > cc1: all warnings being treated as errors
> > > --- inetd.o ---
> > > *** [inetd.o] Error code 1
> > >
> > >
> > > Could anybody please help fix that?
> >
> >
> >
> > Terribly sorry, I forgot to mention a very important detail.
> > My src.conf has the only option now.
> > It's WITHOUT_INET6="YES"
>
> Thanks for that addition- you saved me a little bit of effort
> examining why it's unused. =-)
>
> The inetd build should be clear after r356602, but you'll need to
> build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
> some fundamental issues with mips-gcc{6,9} trying to emit
> __floatunsidf references, but that's a hidden symbol in our libgcc.
>
> I expect to, by the end of the day, either have a fix pending or mark
> it as a BROKEN_OPTION on mips+gcc while we hash out the details , as
> gcc{6,9} is the only option we support for building mips at the
> moment.
>
> Thanks,
>
> Kyle Evans

Thanks a lot, Kyle!
Build process passes further!
Now I'm on r356606 and have these in src.conf
WITHOUT_GOOGLETEST=yes
WITHOUT_INET6="YES"

Getting different error:

===> usr.sbin/sendmail (all)
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:33:19:
warning: 'copyright' defined but not used [-Wunused-const-variable=]
 static const char copyright[] =
   ^
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c: In function
'getname':
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:520:6:
warning: variable 'ppp_state' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
  int ppp_state = 0;
  ^
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:521:6:
warning: variable 'ppp_connection' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
  int ppp_connection = 0;
  ^~
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c: In function
'main':
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:183:6:
warning: variable 'first_sleep' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
  int first_sleep = 1, first_time = 1;
  ^~~
/usr/home/pavel.timofeev/mips/head/libexec/getty/main.c:183:23:
warning: variable 'first_time' might be clobbered by 'longjmp' or
'vfork' [-Wclobbered]
  int first_sleep = 1, first_time = 1;
   ^~
/usr/home/pavel.timofeev/mips/head/libexec/getty/init.c:36:19:
warning: 'rcsid' defined but not used [-Wunused-const-variable=]
 static const char rcsid[] =
   ^
/usr/home/pavel.timofeev/mips/head/libexec/getty/subr.c:36:19:
warning: 'rcsid' defined but not used [-Wunused-const-variable=]
 static const char rcsid[] =
   ^
/usr/local/bin/mips-unknown-freebsd12.0-ld: nc.lo: in function `main':
/usr/home/pavel.timofeev/mips/head/contrib/netcat/netcat.c:365:
warning: warning: mktemp() possibly used unsafely; consider using
mkstemp()
/usr/local/bin/mips-unknown-freebsd12.0-ld:
/usr/home/pavel.timofeev/mips/head/

Re: Can't cross-compile HEAD

[Pavel Timofeev]

чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
>
> Hello
>
> I'm trying to cross-compile HEAD r356551 for mips on my FreeBSD-12.1 amd64.
> I'm using mips-gcc6-6.5.0 and this
> https://github.com/freebsd/freebsd-wifi-build nice project to build
> image for my tl-wdr3600
>
> The error I'm getting is:
> ...
> ===> usr.sbin/fmtree (all)
> ===> usr.bin/vi (all)
> ===> usr.sbin/freebsd-update (all)
> ===> usr.sbin/gpioctl (all)
> ===> usr.sbin/inetd (all)
> /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function
> 'getconfigent':
> /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
> warning: variable 'v4bind' set but not used
> [-Wunused-but-set-variable]
>   int v4bind;
>   ^~
> At top level:
> /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
> warning: 'copyright' defined but not used [-Wunused-const-variable=]
>  static const char copyright[] =
>^
> /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function 
> 'setup':
> /usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
> error: 'netid' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> rpcb_set(sep->se_rpc_prog, i, netid, );
> ^~~
> cc1: all warnings being treated as errors
> --- inetd.o ---
> *** [inetd.o] Error code 1
>
>
> Could anybody please help fix that?



Terribly sorry, I forgot to mention a very important detail.
My src.conf has the only option now.
It's WITHOUT_INET6="YES"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Can't cross-compile HEAD

[Pavel Timofeev]

Hello

I'm trying to cross-compile HEAD r356551 for mips on my FreeBSD-12.1 amd64.
I'm using mips-gcc6-6.5.0 and this
https://github.com/freebsd/freebsd-wifi-build nice project to build
image for my tl-wdr3600

The error I'm getting is:
...
===> usr.sbin/fmtree (all)
===> usr.bin/vi (all)
===> usr.sbin/freebsd-update (all)
===> usr.sbin/gpioctl (all)
===> usr.sbin/inetd (all)
/usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function
'getconfigent':
/usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1614:6:
warning: variable 'v4bind' set but not used
[-Wunused-but-set-variable]
  int v4bind;
  ^~
At top level:
/usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:33:19:
warning: 'copyright' defined but not used [-Wunused-const-variable=]
 static const char copyright[] =
   ^
/usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c: In function 'setup':
/usr/home/pavel.timofeev/mips/head/usr.sbin/inetd/inetd.c:1368:4:
error: 'netid' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
rpcb_set(sep->se_rpc_prog, i, netid, );
^~~
cc1: all warnings being treated as errors
--- inetd.o ---
*** [inetd.o] Error code 1


Could anybody please help fix that?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: emulators/virtualbox-kmod: turn on VIMAGE by default for FreeBSD 12+

[Pavel Timofeev]

24 окт. 2017 г. 0:38 пользователь "Oleg Ginzburg" 
написал:

Hello,

With this change:
https://svnweb.freebsd.org/base?view=revision=324810 I think
should also set VIMAGE options by default in emulators/virtualbox-kmod port
for FreeBSD 12+ via

.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1200051

or by separated meta port ( FLAVOR can help?) :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215336

Without this change we will get panic on FreeBSD 12 + virtualbox-kmod on
boot.



Hi!
First of all I suppose this has to be fixed the way kernel should not
panic, but should just not work (fail to load the module?) and warn about
that.
My 2 cents.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VNET branch destiny

[Pavel Timofeev]

31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
bzeeb-li...@lists.zabbadoz.net> написал:

On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:

Hello, dear freebsd-current@!
>
> There was FreeBSD Foundation report back in 2016Q2 where it told us
> about VNET (VIMAGE) update project sponsored by foundation.
> What is the current situation? Is it committed into base? If not
> what's the plan?
>

Changes are in 12 and 11.   12 has seen more slight fixes due to other
changes that other committers are tracking and I hope they merge to 11.

/bz


Sorry, do you know if there is any plan to include VNET into GENERIC?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VNET branch destiny

[Pavel Timofeev]

31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
bzeeb-li...@lists.zabbadoz.net> написал:

On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:

Hello, dear freebsd-current@!
>
> There was FreeBSD Foundation report back in 2016Q2 where it told us
> about VNET (VIMAGE) update project sponsored by foundation.
> What is the current situation? Is it committed into base? If not
> what's the plan?
>

Changes are in 12 and 11.   12 has seen more slight fixes due to other
changes that other committers are tracking and I hope they merge to 11.

/bz


Thanks a lot for the reply!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

VNET branch destiny

[Pavel Timofeev]

Hello, dear freebsd-current@!

There was FreeBSD Foundation report back in 2016Q2 where it told us
about VNET (VIMAGE) update project sponsored by foundation.
What is the current situation? Is it committed into base? If not
what's the plan?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail

[Pavel Timofeev]

2017-02-02 4:31 GMT+03:00 Xin LI :
> I like this idea.
>
> Note that potentially your patch would make it possible for a jailed
> root to DoS the whole system by locking too much of pages in memory.
> I think it would be sensible to provide a per-jail flag to enable
> doing it, or better, have some finer grained control (e.g. per jail
> quota of permitted locked pages).
>
> Why did the application want to lock pages in main memory, though?

For example, this secret management tool
https://www.vaultproject.io/docs/config/ wants to lock memory for
security (surprise) reason.
It's available as security/vault in our ports tree.

>
> On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé  wrote:
>>
>> I would like to ask if there is a reason I would have to applythe  patch 
>> below to make an application work in a jail.
>> And who's bad? the app too intrusive or the bsd not flexible enough 
>> (allow.mlock?)
>>
>>
>> Index: sys/kern/kern_jail.c
>> ===
>> --- sys/kern/kern_jail.c(revision 313033)
>> +++ sys/kern/kern_jail.c(working copy)
>> @@ -3340,6 +3340,11 @@
>> case PRIV_PROC_SETLOGINCLASS:
>> return (0);
>>
>>
>> +case PRIV_VM_MADV_PROTECT:
>> +case PRIV_VM_MLOCK:
>> +case PRIV_VM_MUNLOCK:
>> +return (0);
>> +
>> default:
>>
>>
>> ___
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OCZ ssdpx-1rvd0120 REVODRIVE support

[Pavel Timofeev]

Just to let you know, eventually, after 11.0 was released, I was able to
install UFS-based FreeBSD 11 on RAID0. The only problem I had was the
loader was unable to boot from it. So I used small flash stick with bootfs
and /boot dir on it. It still works as my home workstation.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OCZ ssdpx-1rvd0120 REVODRIVE support

[Pavel Timofeev]

17 апр. 2016 г. 13:44 пользователь "Rainer Duffner" <rai...@ultra-secure.de>
написал:
>
>
> > Am 17.04.2016 um 11:05 schrieb Pavel Timofeev <tim...@gmail.com>:
> >
> > HI! I've recently got a SSD device. Yes, not a disk, but a device.
> > It's called, i. e. one of the first REVODRIVEs.
> > It's a PCI-express card with two embedded ssd disks about ~ 55GB size.
> > And it's a raid card. Fake software raid. You can set it up as a
> > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured
> > or set it as JBOD or something else.
> > You just won't be able to boot from this device in that case.
> >
>
>
>
> It says „Linux support planned“…

>
> on the product page.

FreeBSD is not Linux =)

Anyway I managed to install Ubuntu on it. Not on all of the configurations
though.



>
> Tried loading the  nvme(4) driver at the countdown?
>
> https://www.freebsd.org/cgi/man.cgi?query=nvme=4
>
>

It's included into GENERIC. But no /dev/nv* devices are found.



> I’d suspect the Intel SSD 750 series would be a better choice…
>

Well, if I had a choise I wouldn't try to ask someone to help me ;)

I'm not a developer, but it seemed to me not a really hard work to add full
support of this device to FreeBSD, because it already work partyally and
detects by graid.


>
>
> Rainer


Probably it's better to attach graid list/status output?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

OCZ ssdpx-1rvd0120 REVODRIVE support

[Pavel Timofeev]

HI! I've recently got a SSD device. Yes, not a disk, but a device.
It's called, i. e. one of the first REVODRIVEs.
It's a PCI-express card with two embedded ssd disks about ~ 55GB size.
And it's a raid card. Fake software raid. You can set it up as a
RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured
or set it as JBOD or something else.
You just won't be able to boot from this device in that case.

So, I tried to install FreeBSD on it. Actually two fbsd version:
FreeBSD 10.3-RELEASE amd64 and FreeBSD-CURRENT amd64 based on r297561
. .
I used RAID0, RAID1 and CONCATENATION raid configurations and UFS and
ZFS (stripe) filesystems. The deivce is seen as raid/r0 and I
installed fbsd on it.
Here is the result of different attemps.


FreeBSD 11-CURRENT r297561 amd64

RAID0
  UFS
MBR - during installation I immediately get 'unknown error -559038242'
GPT - the same and 'Error installing partcode on r0p1' message
  ZFS
MBR - 'Invalid argument' during installation.
GPT - 'Invalid argument' during installation.

RAID1
  UFS
MBR - installs and boots w/o problem
GPT - installs and boots w/o problem
  ZFS
MBR - 'Invalid argument' during installation.
GPT - 'Invalid argument' during installation.

CONCATENATION
  UFS
MBR - 'unknown error -559038242' during installation
GPT - 'unknown error -559038242' during installation
  ZFS
MBR - 'Invalid argument' during installation.
GPT - 'Invalid argument' during installation.



FreeBSD 10.3-RELEASE amd64

RAID0
  UFS
MBR - installs and boots w/o problem
GPT - installs, but doesn't boot. I can see on the screen:
   gptboot: error lba 1280
   gptboot: No /boot/loader on 0:ad(0p2)
   gptboot: No /boot/kernel/kernel on 0:ad(0p2)
  ZFS
MBR - 'Invalid argument' during installation.
GPT - 'Invalid argument' during installation.

RAID1
  UFS
MBR - installs and boots w/o problem
GPT - installs and boots w/o problem
  ZFS
MBR - 'Invalid argument' during installation.
GPT - hangs during installation

CONCATENATION
  UFS
MBR - installs, but panics during boot
GPT - the same, but also I see the following messages on the
screen durin boot
   gpterror 1 lba 234458719
   unable to read gpt header
  ZFS
MBR - 'Invalid argument' during installation.
GPT -  'Invalid argument' during installation.


Also I've attached dmesg and 'geom disk list' output.

I'm ready to try some patches and help to solve this problem!


conc0_dmesg
Description: Binary data


geom_disk_list
Description: Binary data


raid0_dmesg
Description: Binary data


raid1_dmesg
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Hi!
r285785 still isn't MFCed.
RC2 is coming soon.

2015-07-23 10:54 GMT+03:00 Pavel Timofeev tim...@gmail.com:
 Ok, sorry!

 2015-07-23 7:51 GMT+03:00 Wei Hu w...@microsoft.com:
 The TCP offloading is still working on these platforms. There is no flag to 
 distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. 
 Let me know if there is any other way to show it properly.

 Thanks,
 Wei


 -Original Message-
 From: Pavel Timofeev [mailto:tim...@gmail.com]
 Sent: Wednesday, July 22, 2015 9:04 PM
 To: Wei Hu w...@microsoft.com
 Cc: Slawa Olhovchenkov s...@zxy.spb.ru; freebsd-current@freebsd.org; 
 freebsd-virtualizat...@freebsd.org
 Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

 Hi! I see you have done the code for disabling UDP checksum offloading when 
 running on the Hyper-V on Windows Server 2012 and earlier hosts

 https://svnweb.freebsd.org/base?view=revisionrevision=285785

 I tried new CURRENT and it works. Thank you!

 A small note here: while it disables and works it still shows RXCSUM and 
 TSCSUM in iface's options:

 root@proxy:/usr/src # ifconfig hn0
 hn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=31bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6
 ether 00:15:5d:02:9c:09
 inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL

 Is it possible to hide it automatically if it's disabled by new code?


 2015-07-13 11:06 GMT+03:00 Wei Hu w...@microsoft.com:
 We have root caused the problem. This issue happens on the Hyper-Vs on 
 Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the 
 UPD checksum offloading on host side does not work properly. The workaround 
 is to disable UPD checksum offloading in the FreeBSD guest through 
 'ifconfig'. We are also working on a patch to turn off UPD checksum 
 offloading in the netvsc driver when detecting the Hyper-V releases.

 The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 
 hosts.

 Thanks Pavel and Slawa for the support.

 Wei


 -Original Message-
 From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
 virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
 Sent: Wednesday, July 8, 2015 4:06 PM
 To: Slawa Olhovchenkov
 Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
 Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

 Ok, r284746 is the root of the problem. MS DNS works under r284745
 and doesn't work under r284746.
 Slawa, what should I look at in wireshark output?


 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov s...@zxy.spb.ru:
  On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote:
 
  Well, turning off checksum offloading by `ifconfig hn0 -txcsum
  -rxcsum` definitely helps.
 
  As for tcpdump I'm not completely sure if I did it right, but I
  see bad udp cksum phrase:
 
  # tcpdump -i hn0 -vvv -nn udp dst port 53
  tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture
  size
  262144 bytes
  18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.45683  192.168.25.3.53: [bad udp cksum 0xb39e
  - 0xf210!] 52886+ A? ya.ru. (23)
  18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.12575  192.168.25.3.53: [bad udp cksum 0xb39e
  - 0x7365!] 52886+ A? ya.ru. (23)
 
  tcpdump bad udp cksum is normal on FreeBSD host in case checksum
  offload (and may be need only for help finding issuse in code).
  Need wireshark capturing from MS DNS host (or from mirroring port).
 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to freebsd-virtualization-
 unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Ok, sorry!

2015-07-23 7:51 GMT+03:00 Wei Hu w...@microsoft.com:
 The TCP offloading is still working on these platforms. There is no flag to 
 distinguish UDP and TCP offloading, so the RXCSUM and TXCSUM are still set. 
 Let me know if there is any other way to show it properly.

 Thanks,
 Wei


 -Original Message-
 From: Pavel Timofeev [mailto:tim...@gmail.com]
 Sent: Wednesday, July 22, 2015 9:04 PM
 To: Wei Hu w...@microsoft.com
 Cc: Slawa Olhovchenkov s...@zxy.spb.ru; freebsd-current@freebsd.org; 
 freebsd-virtualizat...@freebsd.org
 Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

 Hi! I see you have done the code for disabling UDP checksum offloading when 
 running on the Hyper-V on Windows Server 2012 and earlier hosts

 https://svnweb.freebsd.org/base?view=revisionrevision=285785

 I tried new CURRENT and it works. Thank you!

 A small note here: while it disables and works it still shows RXCSUM and 
 TSCSUM in iface's options:

 root@proxy:/usr/src # ifconfig hn0
 hn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=31bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6
 ether 00:15:5d:02:9c:09
 inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL

 Is it possible to hide it automatically if it's disabled by new code?


 2015-07-13 11:06 GMT+03:00 Wei Hu w...@microsoft.com:
 We have root caused the problem. This issue happens on the Hyper-Vs on 
 Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the 
 UPD checksum offloading on host side does not work properly. The workaround 
 is to disable UPD checksum offloading in the FreeBSD guest through 
 'ifconfig'. We are also working on a patch to turn off UPD checksum 
 offloading in the netvsc driver when detecting the Hyper-V releases.

 The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 
 hosts.

 Thanks Pavel and Slawa for the support.

 Wei


 -Original Message-
 From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
 virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
 Sent: Wednesday, July 8, 2015 4:06 PM
 To: Slawa Olhovchenkov
 Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
 Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

 Ok, r284746 is the root of the problem. MS DNS works under r284745
 and doesn't work under r284746.
 Slawa, what should I look at in wireshark output?


 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov s...@zxy.spb.ru:
  On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote:
 
  Well, turning off checksum offloading by `ifconfig hn0 -txcsum
  -rxcsum` definitely helps.
 
  As for tcpdump I'm not completely sure if I did it right, but I
  see bad udp cksum phrase:
 
  # tcpdump -i hn0 -vvv -nn udp dst port 53
  tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture
  size
  262144 bytes
  18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.45683  192.168.25.3.53: [bad udp cksum 0xb39e
  - 0xf210!] 52886+ A? ya.ru. (23)
  18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.12575  192.168.25.3.53: [bad udp cksum 0xb39e
  - 0x7365!] 52886+ A? ya.ru. (23)
 
  tcpdump bad udp cksum is normal on FreeBSD host in case checksum
  offload (and may be need only for help finding issuse in code).
  Need wireshark capturing from MS DNS host (or from mirroring port).
 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to freebsd-virtualization-
 unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

new kern.vt.splash_cpu_style wrong description

[Pavel Timofeev]

Hi!

I've updated my CURRENT and tried new feature which was introduced by
this commit https://svnweb.freebsd.org/base?view=revisionrevision=285766

I found that description for one of those sysctl is wrong:
# sysctl -d kern.vt.splash_cpu_style
kern.vt.splash_cpu_style: Draw logo style (0=Beastie, 1=Alternate
beastie, 2=Orb)

Right description should be
0 = Alternative beastie
1 = Beastie
2 = Orb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

I rebuilt only kernel if it matters. Not the world.

2015-07-22 16:04 GMT+03:00 Pavel Timofeev tim...@gmail.com:
 Hi! I see you have done the code for disabling UDP checksum offloading
 when running on the Hyper-V on Windows Server 2012 and earlier hosts

 https://svnweb.freebsd.org/base?view=revisionrevision=285785

 I tried new CURRENT and it works. Thank you!

 A small note here: while it disables and works it still shows RXCSUM
 and TSCSUM in iface's options:

 root@proxy:/usr/src # ifconfig hn0
 hn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=31bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6
 ether 00:15:5d:02:9c:09
 inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63
 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL

 Is it possible to hide it automatically if it's disabled by new code?


 2015-07-13 11:06 GMT+03:00 Wei Hu w...@microsoft.com:
 We have root caused the problem. This issue happens on the Hyper-Vs on 
 Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the 
 UPD checksum offloading on host side does not work properly. The workaround 
 is to disable UPD checksum offloading in the FreeBSD guest through 
 'ifconfig'. We are also working on a patch to turn off UPD checksum 
 offloading in the netvsc driver when detecting the Hyper-V releases.

 The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 
 hosts.

 Thanks Pavel and Slawa for the support.

 Wei


 -Original Message-
 From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
 virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
 Sent: Wednesday, July 8, 2015 4:06 PM
 To: Slawa Olhovchenkov
 Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
 Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

 Ok, r284746 is the root of the problem. MS DNS works under r284745 and
 doesn't work under r284746.
 Slawa, what should I look at in wireshark output?


 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov s...@zxy.spb.ru:
  On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote:
 
  Well, turning off checksum offloading by `ifconfig hn0 -txcsum
  -rxcsum` definitely helps.
 
  As for tcpdump I'm not completely sure if I did it right, but I see
  bad udp cksum phrase:
 
  # tcpdump -i hn0 -vvv -nn udp dst port 53
  tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture size
  262144 bytes
  18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.45683  192.168.25.3.53: [bad udp cksum 0xb39e -
  0xf210!] 52886+ A? ya.ru. (23)
  18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.12575  192.168.25.3.53: [bad udp cksum 0xb39e -
  0x7365!] 52886+ A? ya.ru. (23)
 
  tcpdump bad udp cksum is normal on FreeBSD host in case checksum
  offload (and may be need only for help finding issuse in code). Need
  wireshark capturing from MS DNS host (or from mirroring port).
 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to freebsd-virtualization-
 unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Hi! I see you have done the code for disabling UDP checksum offloading
when running on the Hyper-V on Windows Server 2012 and earlier hosts

https://svnweb.freebsd.org/base?view=revisionrevision=285785

I tried new CURRENT and it works. Thank you!

A small note here: while it disables and works it still shows RXCSUM
and TSCSUM in iface's options:

root@proxy:/usr/src # ifconfig hn0
hn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=31bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6
ether 00:15:5d:02:9c:09
inet 192.168.25.26 netmask 0xffc0 broadcast 192.168.25.63
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL

Is it possible to hide it automatically if it's disabled by new code?


2015-07-13 11:06 GMT+03:00 Wei Hu w...@microsoft.com:
 We have root caused the problem. This issue happens on the Hyper-Vs on 
 Windows Server 2012 (Win 8.0) and earlier releases. On these releases, the 
 UPD checksum offloading on host side does not work properly. The workaround 
 is to disable UPD checksum offloading in the FreeBSD guest through 
 'ifconfig'. We are also working on a patch to turn off UPD checksum 
 offloading in the netvsc driver when detecting the Hyper-V releases.

 The UDP checksum offloading works fine on Windows Server 2012R2 and Win 8.1 
 hosts.

 Thanks Pavel and Slawa for the support.

 Wei


 -Original Message-
 From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
 virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
 Sent: Wednesday, July 8, 2015 4:06 PM
 To: Slawa Olhovchenkov
 Cc: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
 Subject: Re: MS DNS doesn't answer to CURRENT under Hyper-V

 Ok, r284746 is the root of the problem. MS DNS works under r284745 and
 doesn't work under r284746.
 Slawa, what should I look at in wireshark output?


 2015-07-07 18:49 GMT+03:00 Slawa Olhovchenkov s...@zxy.spb.ru:
  On Tue, Jul 07, 2015 at 06:04:46PM +0300, Pavel Timofeev wrote:
 
  Well, turning off checksum offloading by `ifconfig hn0 -txcsum
  -rxcsum` definitely helps.
 
  As for tcpdump I'm not completely sure if I did it right, but I see
  bad udp cksum phrase:
 
  # tcpdump -i hn0 -vvv -nn udp dst port 53
  tcpdump: listening on hn0, link-type EN10MB (Ethernet), capture size
  262144 bytes
  18:01:19.139994 IP (tos 0x0, ttl 64, id 61218, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.45683  192.168.25.3.53: [bad udp cksum 0xb39e -
  0xf210!] 52886+ A? ya.ru. (23)
  18:01:24.140544 IP (tos 0x0, ttl 64, id 17293, offset 0, flags
  [none], proto UDP (17), length 51)
  192.168.25.26.12575  192.168.25.3.53: [bad udp cksum 0xb39e -
  0x7365!] 52886+ A? ya.ru. (23)
 
  tcpdump bad udp cksum is normal on FreeBSD host in case checksum
  offload (and may be need only for help finding issuse in code). Need
  wireshark capturing from MS DNS host (or from mirroring port).
 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to freebsd-virtualization-
 unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

No, I don't even know what VMDepot is, sorry! Didn't know ;)

2015-07-07 16:58 GMT+03:00 Glen Barber g...@freebsd.org:
 BTW, are you using the images from VMDepot?  If so, this was MFC'd after
 the recent images.  I can easily regenerate an updated image, if you are
 using those.

 Glen

 On Tue, Jul 07, 2015 at 04:55:39PM +0300, Pavel Timofeev wrote:
 Wow, r284746 was MFCed to 10 STABLE!
 I should hurry up!

 2015-07-07 16:26 GMT+03:00 Pavel Timofeev tim...@gmail.com:
  Ok, I'll try r284745 and then r284746 and see what happens.
 
  2015-07-07 16:06 GMT+03:00 Wei Hu w...@microsoft.com:
  -Original Message-
  From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
  virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
  Sent: Tuesday, July 7, 2015 7:51 PM
  To: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
  Subject: MS DNS doesn't answer to CURRENT under Hyper-V
 
  Hi!
  I have a test virtual machine which runs CURRENT under Hyper-V. It's
  amd64 r285198 now.
  It can't get any response from MS DNS server. Well, it could two or three
  weeks ago, but after upgrade it's not able to do it anymore.
  Google DNS answers without problems meanwhile (sic!).
 
  What I do:
  # host google.ru 192.168.25.3
  I see that MS DNS (192.168.25.3) server receives these packets, but 
  ignores
  them.
  And no matter how my system asks MS DNS. Every daemon can't get
  response too.
 
  I know that nothing was changed in MS DNS server. No doubt.
  Then I tried different available CURRENT snapshot ISOs.
 
  FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso - MS DNS does
  not answer.
 
  FreeBSD-11.0-CURRENT-amd64-20150625-r284814-disc1.iso - MS DNS does
  not answer.
 
  FreeBSD-11.0-CURRENT-amd64-20150618-r284544-disc1.iso - MS DNS
  answers!
 
  So something was committed to CURRENT between 20150618 and 20150625.
  This something ruins communication with MS DNS.
 
  There was a commit for Hyper-V TSO and checksum offloading support  
  (r284746) on
  June 24th. I think this commit is the cause. Can you verify the MS DNS 
  behavior between
  The builds of June 23rd and 24th? I will take a look of this issue 
  tomorrow.
 
  Thanks,
  Wei
 
 
 
 ___
 freebsd-virtualizat...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
 To unsubscribe, send any mail to 
 freebsd-virtualization-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Hi!
I have a test virtual machine which runs CURRENT under Hyper-V. It's
amd64 r285198 now.
It can't get any response from MS DNS server. Well, it could two or
three weeks ago, but after upgrade it's not able to do it anymore.
Google DNS answers without problems meanwhile (sic!).

What I do:
# host google.ru 192.168.25.3
I see that MS DNS (192.168.25.3) server receives these packets, but
ignores them.
And no matter how my system asks MS DNS. Every daemon can't get response too.

I know that nothing was changed in MS DNS server. No doubt.
Then I tried different available CURRENT snapshot ISOs.

FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso - MS DNS does not answer.

FreeBSD-11.0-CURRENT-amd64-20150625-r284814-disc1.iso - MS DNS does not answer.

FreeBSD-11.0-CURRENT-amd64-20150618-r284544-disc1.iso - MS DNS answers!

So something was committed to CURRENT between 20150618 and 20150625.
This something ruins communication with MS DNS.

Then I tried latest
FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso on bare metal -
MS DNS answered!

Looks like that something is related to Hyper-V code.

Maybe it changes packets somehow? I can gather and provide more info
(tcpdump?) if you ask, it's not a problem!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Ok, I'll try r284745 and then r284746 and see what happens.

2015-07-07 16:06 GMT+03:00 Wei Hu w...@microsoft.com:
 -Original Message-
 From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
 virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
 Sent: Tuesday, July 7, 2015 7:51 PM
 To: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
 Subject: MS DNS doesn't answer to CURRENT under Hyper-V

 Hi!
 I have a test virtual machine which runs CURRENT under Hyper-V. It's
 amd64 r285198 now.
 It can't get any response from MS DNS server. Well, it could two or three
 weeks ago, but after upgrade it's not able to do it anymore.
 Google DNS answers without problems meanwhile (sic!).

 What I do:
 # host google.ru 192.168.25.3
 I see that MS DNS (192.168.25.3) server receives these packets, but ignores
 them.
 And no matter how my system asks MS DNS. Every daemon can't get
 response too.

 I know that nothing was changed in MS DNS server. No doubt.
 Then I tried different available CURRENT snapshot ISOs.

 FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso - MS DNS does
 not answer.

 FreeBSD-11.0-CURRENT-amd64-20150625-r284814-disc1.iso - MS DNS does
 not answer.

 FreeBSD-11.0-CURRENT-amd64-20150618-r284544-disc1.iso - MS DNS
 answers!

 So something was committed to CURRENT between 20150618 and 20150625.
 This something ruins communication with MS DNS.

 There was a commit for Hyper-V TSO and checksum offloading support  (r284746) 
 on
 June 24th. I think this commit is the cause. Can you verify the MS DNS 
 behavior between
 The builds of June 23rd and 24th? I will take a look of this issue tomorrow.

 Thanks,
 Wei



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: MS DNS doesn't answer to CURRENT under Hyper-V

[Pavel Timofeev]

Wow, r284746 was MFCed to 10 STABLE!
I should hurry up!

2015-07-07 16:26 GMT+03:00 Pavel Timofeev tim...@gmail.com:
 Ok, I'll try r284745 and then r284746 and see what happens.

 2015-07-07 16:06 GMT+03:00 Wei Hu w...@microsoft.com:
 -Original Message-
 From: owner-freebsd-virtualizat...@freebsd.org [mailto:owner-freebsd-
 virtualizat...@freebsd.org] On Behalf Of Pavel Timofeev
 Sent: Tuesday, July 7, 2015 7:51 PM
 To: freebsd-current@freebsd.org; freebsd-virtualizat...@freebsd.org
 Subject: MS DNS doesn't answer to CURRENT under Hyper-V

 Hi!
 I have a test virtual machine which runs CURRENT under Hyper-V. It's
 amd64 r285198 now.
 It can't get any response from MS DNS server. Well, it could two or three
 weeks ago, but after upgrade it's not able to do it anymore.
 Google DNS answers without problems meanwhile (sic!).

 What I do:
 # host google.ru 192.168.25.3
 I see that MS DNS (192.168.25.3) server receives these packets, but ignores
 them.
 And no matter how my system asks MS DNS. Every daemon can't get
 response too.

 I know that nothing was changed in MS DNS server. No doubt.
 Then I tried different available CURRENT snapshot ISOs.

 FreeBSD-11.0-CURRENT-amd64-20150630-r284969-disc1.iso - MS DNS does
 not answer.

 FreeBSD-11.0-CURRENT-amd64-20150625-r284814-disc1.iso - MS DNS does
 not answer.

 FreeBSD-11.0-CURRENT-amd64-20150618-r284544-disc1.iso - MS DNS
 answers!

 So something was committed to CURRENT between 20150618 and 20150625.
 This something ruins communication with MS DNS.

 There was a commit for Hyper-V TSO and checksum offloading support  
 (r284746) on
 June 24th. I think this commit is the cause. Can you verify the MS DNS 
 behavior between
 The builds of June 23rd and 24th? I will take a look of this issue tomorrow.

 Thanks,
 Wei



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Can't install latest CURRENT

[Pavel Timofeev]

Hi!
I've downloaded today's CURRENT snapshot and tried to install it.
It fails on setting root password with following message:


FreeBSD Installer
=

Please select a password for the system management account (root):
Changing local password for root
New Password:
passwd: pam_chauthtok(): conversation failure
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Can't boot with geom_part_(gpt|mbr|bsd|ebr)

[Pavel Timofeev]

Kernel can't boot is a common idea.
I did the tests for each geom_part and described it in PR.

Some transcription:
boot stops (on usb detect) - boot stops, not hangs, you can push
Pause/Break and surf through system boot messages.
http://img-fotki.yandex.ru/get/5606/16519813.0/0_83860_a4bf85d_orig

can't mount fs:
http://img-fotki.yandex.ru/get/6201/16519813.0/0_83861_e809a6e3_orig

I'm sorry for bad photos. Obtained from 9.0R i386


1 марта 2012 г. 20:08 пользователь Andriy Gapon a...@freebsd.org написал:
 on 01/03/2012 09:27 Pavel Timofeev said the following:
 Hi!
 Just add to loader.conf these options
 geom_part_gpt_load=YES
 geom_part_bsd_load=YES
 geom_part_ebr_load=YES
 geom_part_mbr_load=YES
 and your kernel can't boot

 Thank you for the report.
 Could you please provide some technical information?  kernel can't boot is a
 little bit too unspecific.  Any particular error messages, etc?

 I have posted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=165573

 --
 Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Can't boot with geom_part_(gpt|mbr|bsd|ebr)

[Pavel Timofeev]

Hi!
Just add to loader.conf these options
geom_part_gpt_load=YES
geom_part_bsd_load=YES
geom_part_ebr_load=YES
geom_part_mbr_load=YES
and your kernel can't boot

I have posted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=165573
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Can't boot with geom_part_(gpt|mbr|bsd|ebr)

[Pavel Timofeev]

I will make translation tomorrow.
But you can see it by yourself, just edit your loader.conf =)

1 марта 2012 г. 20:08 пользователь Andriy Gapon a...@freebsd.org написал:
 on 01/03/2012 09:27 Pavel Timofeev said the following:
 Hi!
 Just add to loader.conf these options
 geom_part_gpt_load=YES
 geom_part_bsd_load=YES
 geom_part_ebr_load=YES
 geom_part_mbr_load=YES
 and your kernel can't boot

 Thank you for the report.
 Could you please provide some technical information?  kernel can't boot is a
 little bit too unspecific.  Any particular error messages, etc?

 I have posted PR http://www.freebsd.org/cgi/query-pr.cgi?pr=165573

 --
 Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fresh installed Freebsd 9 don't boot from hd

[Pavel Timofeev]

Thank you! I see this fix in 9 STABLE.
Works)

2011/11/8 John Baldwin j...@freebsd.org:
 On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote:
 FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov  8 20:52:11 MSK
 2011     mox@accessor:/usr/obj/usr/src/sys/GENERIC  amd64
 RC2 is coming. Nothing changed.

 Sorry, haven't been able to merge them to 9 yet.

 2011/10/25 John Baldwin j...@freebsd.org:
  On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
  On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
 
   On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
   Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
  
   GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
  
          v86.ds = VTOPSEG(params);
          v86.esi = VTOPOFF(params);
  
   Changed this to params. Also changed sector_size to uint16_t as noted
   by Andriy. Boots perfectly! (Tested with gcc and clang)
 
  I'd like to test these patches on my Supermicro machine as well.
  Unfortunately, I don't know how to go about it, but I'm hopeful to be able 
  to
  figure it out with some basic instructions. I'm currently running a fresh 
  RC1
  install, and I'm able to boot the system if I set the BIOS to IDE mode, 
  rather
  than AHCI.
 
  Any help would be much appreciated,
 
  I just committed them to HEAD (226748 along with a cleanup in 226746).  
  They
  should backport to 9.
 
  --
  John Baldwin
 


 --
 John Baldwin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fresh installed Freebsd 9 don't boot from hd

[Pavel Timofeev]

FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov  8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC  amd64
RC2 is coming. Nothing changed.

2011/10/25 John Baldwin j...@freebsd.org:
 On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
 On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:

  On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
  Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
 
  GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
 
         v86.ds = VTOPSEG(params);
         v86.esi = VTOPOFF(params);
 
  Changed this to params. Also changed sector_size to uint16_t as noted
  by Andriy. Boots perfectly! (Tested with gcc and clang)

 I'd like to test these patches on my Supermicro machine as well.
 Unfortunately, I don't know how to go about it, but I'm hopeful to be able to
 figure it out with some basic instructions. I'm currently running a fresh RC1
 install, and I'm able to boot the system if I set the BIOS to IDE mode, rather
 than AHCI.

 Any help would be much appreciated,

 I just committed them to HEAD (226748 along with a cleanup in 226746).  They
 should backport to 9.

 --
 John Baldwin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fresh installed Freebsd 9 don't boot from hd

[Pavel Timofeev]

2011/10/24 Dimitry Andric d...@freebsd.org

 On 2011-10-23 21:56, Dennis Koegel wrote:

 On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote:

 I found a document that suggests a possibility of BIOS writing more bytes
 to the
 array than its current size of 0x42: [...]
 Could you please test this hypothesis by trying the following patch?


 With -O1 and this patch, it boots. Thank you!


 If you have some time, can you also re-check the other cases you listed
 before?  E.g.:


 gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
 -fno-unit-at-a-time \
-mno-align-long-strings -mrtd [from before r225530]:
 gcc -Os -mrtd:
 gcc -O1 -mrtd:
 gcc -O1:
 gcc -O0:
 gcc -Os:

 clang -O1:
 clang -Os:
 clang -Oz:


My 5 cents:
tested on my HP Proliant DL360 G5 with Andriy's patch
clang -O1: ok (VirtualBox with ahci boots too)
clang -Os: ok
clang -Oz: ok



 Thanks. :)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fresh installed Freebsd 9 don't boot from hd

[Pavel Timofeev]

2011/10/21 Dennis Koegel d...@neveragain.de

 On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote:
  I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i
 mirror)
  as test. [...]
  It was fresh install and I choose guided partitioning (GPT)
  But after reboot my server don't boot from hd.

 We have the same issue on a DL580 G7. Install runs fine, but when it's
 time for the first boot, the bootcode emits a single '-' (where usually
 it would be spinning for a moment while loading), hangs for about two
 seconds, and then reboots.

 I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it
 worked fine. Also, manually adding the GPT label, partitions and
 bootcode using gpart, then rebooting, shows the exact same behaviour
 (this was done using the BETA3 Live CD).

 I suspect it's something in the vicinity of pmbr bootcode vs.  newer
 HP BIOS.

I don't know, but earlier snapshots, for example,
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201105/FreeBSD-9.0-CURRENT-201105-amd64-dvd1.iso
doesn't have such problems.
Does anybody have BETA-2 iso?


 (BTW, not related to this issue: hw.memtest.tests=0 should be default.
 The kernel on a system with 128 GB of RAM needs about two minutes (!)
 before emitting a single line of output. At first we didn't know about
 this test and thought there was a serious problem.)

 - D.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fresh installed Freebsd 9 don't boot from hd

[Pavel Timofeev]

2011/10/21 Dennis Koegel d...@neveragain.de

 On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote:
  I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i
 mirror)
  as test. [...]
  It was fresh install and I choose guided partitioning (GPT)
  But after reboot my server don't boot from hd.

 We have the same issue on a DL580 G7. Install runs fine, but when it's
 time for the first boot, the bootcode emits a single '-' (where usually
 it would be spinning for a moment while loading), hangs for about two
 seconds, and then reboots.

 I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it
 worked fine. Also, manually adding the GPT label, partitions and
 bootcode using gpart, then rebooting, shows the exact same behaviour
 (this was done using the BETA3 Live CD).

 I suspect it's something in the vicinity of pmbr bootcode vs.  newer
 HP BIOS.

 (BTW, not related to this issue: hw.memtest.tests=0 should be default.
 The kernel on a system with 128 GB of RAM needs about two minutes (!)
 before emitting a single line of output. At first we didn't know about
 this test and thought there was a serious problem.)

My proliant have 1Gb RAM =)



 - D.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Fresh installed Freebsd 9 don't boot from hd

[Pavel Timofeev]

I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror)
as test.
It was installed long time ago and often I did csup/rebuild.
Yesterday I updated it to 9.0-RC1 and everything was fine.

Today I downloaded BETA3 iso and tried to install it.
bsdinstall is good. CD ISO boots and installs good.
It was fresh install and I choose guided partitioning (GPT)
But after reboot my server don't boot from hd.
I see HP splash screen, checks for iLo, smart array and when I should see
message like Attempting boot from harddrive and then BTX it reboots.

If I use MBR (new install) - system boots from hd normally.

I tied 10.0-HEAD-20111018-JPSNAP snapshot from
http://pub.allbsd.org/FreeBSD-snapshots/
I tried 9.0-RC1 iso that sometimes appears in ftp.freebsd.org
Same story.

Is it bsdinstall bug?

P.S. in VirtualBox everything is fine.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/14 David Wolfskill da...@catwhisker.org

 On Fri, Oct 14, 2011 at 11:55:28AM +0400, Pavel Timofeev wrote:
  That's what most people think.

 Could be.  But to the extent that it's true, I have no reason to believe
 that it's a perspective that is held uniquely (or even principally) about
 FreeBSD.

  Hi!
 
  I would like to say that most freebsd users don't try CURRENT, but try
  BETAs-x, RCs-x.

 Errr... I'll suggest that most folks who posit what most folks do
 don't actually determine this empirically.  Some of them probably engage
 in something called projection (in lieu of performing appropriate
 polling, for example).

Ok, for example, more emails and bug reports appears in mailing lists after
CURRENT stabilization.



  Why? Because most users don't like compile new kernel and world. It's
  tediously.

 Errr...  So what?  Doing it doesn't prevent one from doing other things
 (within reason), and the process gets done when it's done.  And it's the
 computer doing the tedious stuff -- which is something at which they
 excel.

 I'm in the habit of tracking stable/8, stable/9, and head on a daily
 basis on a personal build machine and on my laptop.  I also update all
 of the installed ports on each machine daily.

It's only you. Good habbit. But this isn't often, for example, my colleagues
and friends don't track it.
They are just users (consumers).



 I don't expect most folks to do that; actually, I don't expect anyone
 else to do (precisely) that.

Right.


  You need to download a CURRENT snapshot iso, to install, csup, and then
 to
  build kernel and world.

 Really?  I don't think I've ever used a snapshot.  I do maintain a
 private mirror of the FreeBSD CVS  SVN repositories (and mirror those
 to my laptop).  I find the tracking process fairly straightforward,
 and only rarely surprising (though usually, if it is surprising, it's
 not in an especially good way -- but then I'm occasionally able to
 help at least provide some encouragement to fix the cause of the
 surprise).

It's funny =). Not everyone maintains its mirrors.
For example, I didn't use my CURRENT (previously installed to VM) about 4
months. And now I want to try new CURRENT. What I need to do? Csup and
build? No, downloading and installing fresh snapshot would be more quickly.
There is changes in bsdinstall while BETA-3 and if I want to test it what i
need to do?



  FreeBSD project builds CURRENT snapshot every month, but not always. And
  this volatility is bad.
  Month is a big period. Very big, imo. For example, 10 day period would be
  great!

 If you want finer-grained updates, one way is to use the source.  The
 project still maintains the SVN-to-CVS exporting process, and a network
 of public CVS mirrors around the planet.  The cvs program is in the
 FreeBSD base system.  You have the resources necessary to do this, if
 you want to do so.

See above



  And when BETA/RC time comes users rush like mad to test it. And they find
  errors and bugs. Writing PR, emails and even !patches!

 There are certainly some folks whose first exposure to a new release is
 in the later stages of the release process.  Changing parameters (such
 as the duration of the process) may affect the population distribution
 some, but it won't change the fact that there are some folks who will
 not test early enough to raise some valid objections or concerns in
 sufficient time to have them addressed in a completely satisfactory
 manner prior to the release.  This is something that appears to involve
 rather deep-sewated aspects of human nature, and it is not in the power
 of any organization to prevent it.  The best anyone (or any group) can
 do is find ways to mitigate it, and learn to move on.

It's also correctly.




 But the lion's share of these patches doesn't get into the coming BETA or
 RC.
  Maintainers say I don't have time [to test it] or It's too late.

 Given that the process is intended to produce a release, there comes a
 time when it is necessary to draw the line and cut the release.

 Software is rarely perfect.  I'd venture that software of sufficient
 complexity is never perfect.  I'll also ventire that FreeBSD -- much
 as I enjoy using and working with it -- is sufficiently complex as to be
 imperfect.  In fact, it is a work in progress.

 This ought not be either surprising or unfamiliar to anyone who has been
 on the planet long enough to recognize the parallels with humans --
 remarkably few humans are perfect, either, after all.  :-}  [And yes, I
 include myself as imperfect -- certainly as long as I'm still
 breathing.]

Yes, you're right.



  Why is it late? I'm talking about only BUGS (PRs with patches), not new
  features. Let's users test it! In coming BETA/RC. Where are we in a
 hurry?
  The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the
 only
  purpose of it.
  Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE.
  Because of this situation most people says x.0 RELASE isn't

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/15 George Kontostanos gkontos.m...@gmail.com

 On Fri, Oct 14, 2011 at 10:55 AM, Pavel Timofeev tim...@gmail.com wrote:
  That's what most people think.

  I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be
  longer. Six months, for example.
  New STABLE branch is very important!

 IMHO different OS releases (Unix or not) are usually at the state of
 FreeBSD current regarding stability. FreeBSD late BETA and early RC
 are usually very stable. Therefore the approximate one month period
 between the first beta and the release is adequate time.

 Many users are reluctant to follow stable because they have to go
 through the wolrd  kernel procedure. Since freebsd-update exists as
 a means of binary upgrading a system through releases, I don't think
 that it would be a bad idea to be able to use is for stable as well.
 Let's assume that we would have monthly minor releases something like
 9.0.1, 9.0.2 etc.   That could ease the fear of .0 release.

It's not bad idea.



 This is coming from someone who is using current all the time for
 workstations and stable for production servers and never uses
 freebsd-update!

 Best Regards

 --
 George Kontostanos
 aisecure.net

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/15 Martin Sugioarto mar...@sugioarto.com

 Am Fri, 14 Oct 2011 11:55:28 +0400
 schrieb Pavel Timofeev tim...@gmail.com:

  That's what most people think.

 Hi!

 I'm not thinking this. This is made up by users who only adapt slowly
 to changes and features. Look at the whole crowd which got furious about
 the new Microsoft Office. I tell you, in one year, no one will cry about
 it anymore. Sometimes, I feel like I am the only who is happy about good
 ideas, even when they change something drastically. The most people
 think Whoa... I have to learn again!... and then silently accept it
 when it is very late, because everyone else already migrated.

No, i don't care about new features or big changes. I love it!
I care about bugs, that people finds while BETA/RC.



 This has nothing to do with release quality, because the efforts to
 make a production release of x.0 are much higher, in my opinion. So the
 quality is generally better, if you have enough time to make this
 release.

 For me the worst FreeBSD release ever was 5.3. Even 5.0 BETAs worked
 better on my hardware. I also stopped using FreeBSD at that time until
 7.0 BETAs arrived.

  And when BETA/RC time comes users rush like mad to test it. And they
  find errors and bugs. Writing PR, emails and even !pathes!
  But the lion's share of these pathes doesn't get into the coming BETA
  or RC.

 Yes. I'm waiting for my /sbin/dump fix to get verified and committed.
 It's really disappointing to see the next release without a functioning
 backup possibility (for my configuration here).


kern/160678? A good example.
I give 5$ that this fix won't be in 9.0 RELEASE =)
I know a few other important PRs that won't be in 9.0 RELEASE.
Thats why I wrote initial email.


 Fortunately, I don't see a fixed release date, yet. I hope the
 developers fix as much as possible even when we see 9.0R in late 2012.

 --
 Martin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/15 Thomas Mueller mueller6...@bellsouth.net

  MHO different OS releases (Unix or not) are usually at the state of
  FreeBSD current regarding stability. FreeBSD late BETA and early RC
  are usually very stable. Therefore the approximate one month period
  between the first beta and the release is adequate time.

 I see your point, especially after installing NetBSD on my new computer and
 having big problems, like not being able to startx or not neing able to boot
 at all.

 On the old computer, I also had big problems with NetBSD, including
 release, stable and current versions.

 Building FreeBSD or NetBSD from source might be not feasible on older
 computers short on RAM and/or disk space.

Bingo! I have atom-based computers and building world is torture.




 There are more frequent current FreeBSD snapshots available on

 http://pub.allbsd.org/pub/FreeBSD-snapshots/

 This site also has snapshots for other BSDs.

Great! But it's not official. If this link was in freebsd.org it would be
cool.


 Tom


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/19 Adrian Chadd adr...@freebsd.org

 On 19 October 2011 16:04, Pavel Timofeev tim...@gmail.com wrote:

  kern/160678? A good example.
  I give 5$ that this fix won't be in 9.0 RELEASE =)
  I know a few other important PRs that won't be in 9.0 RELEASE.
  Thats why I wrote initial email.

 Kirk fixed it in -HEAD. I hope he'll get it tested and backported to
 stable/9 before release.
 If you'd like to help then please re-create the issue on a stable/9
 system, apply the fix, verify it works and let him know!

Yes, I helps. I test everything that comes across to me when I have free
time.
And I already did tests in such situation.
For example:
http://www.freebsd.org/cgi/query-pr.cgi?pr=160943 (there is hope)
or http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 (little hope. it's not
me, but there I was noisy.)





 Adrian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/19 Adrian Chadd adr...@freebsd.org

 On 19 October 2011 15:42, Pavel Timofeev tim...@gmail.com wrote:

  =) Thats why we don't have much people in FreeBSD. FreeBSD for users? or
  developers?

  The big problem is that these conversations are not wanted everyone.
  Nobody cares. For example, Vadim Goncharov wrote big mail with
 description
  of various problems in FreeBSD (organozation|system|ports|etc). Big
  consersation and all forgotten. Nothing has changed and will not change.

 Oh the conversations are wanted. People to build solutions to problems
 are more wanted.

I'd love to, but I often lack the knowledge and skills.
I'm tring to change that.



 Some of what Vadim mentioned is being addressed (ports/package
 infrastructure.) The other stuff is likely up for discussion post
 9.0-RELEASE.

Excelent. But I got carried away.



 Remember - best way to help is to grab a problem and hack on it until
 it's fixed.

Yes, I know. Usually that's what i'm doing or want to do.


 There's only so much that discussion, planning and more
 discussion can do.
 (Unless you're an AI researcher and can write systems to take
 discussion/planning and output code. Then we'd all love to hear from
 you.)




 Adrian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/19 Johan Hendriks joh.hendr...@gmail.com

  Pavel Timofeev schreef:

  I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be  
 longer. Six months, for example.  New STABLE branch is very important!

   So is opening head up to allow developers to work on and commit new 
 code.  As with many things in engineering, there's a cost/benefit trade-off. 
  RE is doing a remarkable job, IMO.

  Sorry, don't misunderstand me. I'm talking about new STABLE branch.
 Maybe we need to change things like BETA-1(2) is still CURRENT. For
 example, let's introduce a new concept ALPHA (which will be CURRENT). And
 BETAs will be STABLE.

  If you want a really stable OS ,then there is never going to be a release.
 In CURRENT, there are a lot of changes already that do not go into 9.0
 You _must_ take a point in time to release the release, even with known and
 pending patches.
 If you are going to wait, then there will never be a release.

Yes, I agree, but there must be a golden mean.


 The 9.0.1, 9.0.2 branch idea is very apealling i must say.
 But here the same problem do we wait for that one patch that is waiting
 MFC?
 So the same problem when do you release the 9.0.x version!

 Releasing the release is a trade-off.

Ok, I understood.



 I do like the current approach that FreeBSD uses.
 The only thing i think could be better is to slow down the release cycle.

Yes, me too

I would like to see a release like 9.8, which then have an enormous real
 world exposure and where all possible bugs are ironed out.

Well, it's a large number. x.3(4) - yes.
However, progress is developing faster and faster and we need to keep up
with him, so you're right below.

A release that you could use without hesitating  for your daily tasks.
 But then there is a trade-off again, all new features that are pending in
 CURRENT do not get as much exposure as we would like, and then when the new
 CURRENT become the next production release, we could have a much more
 buggier release then normal.

 So i am glad i do not have to make these decisions.** :D

 regards
 Johan Hendriks









___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x.0 RELASE isn't for production.

[Pavel Timofeev]

2011/10/19 Adrian Chadd adr...@freebsd.org

 On 19 October 2011 19:38, Pavel Timofeev tim...@gmail.com wrote:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=160943 (there is hope)
  or http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 (little hope. it's
 not
  me, but there I was noisy.)

 Just send the committer a polite, nicely worded email and see if
 they'll submit it for backporting to stable/9.

Big sorry, if I was impolite. My english is very poor and I don't know how
to write civilly.



 There's a bunch of fixes that I've not backported from -head to
 stable/9 because I've not received anywhere near enough feedback from
 people to be sure it hasn't broken things this late in the release
 cycle.



 Adrian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

x.0 RELASE isn't for production.

[Pavel Timofeev]

That's what most people think.

Hi!

I would like to say that most freebsd users don't try CURRENT, but try
BETAs-x, RCs-x.
Why? Because most users don't like compile new kernel and world. It's
tediously.
You need to download a CURRENT snapshot iso, to install, csup, and then to
build kernel and world.
FreeBSD project builds CURRENT snapshot every month, but not always. And
this volatility is bad.
Month is a big period. Very big, imo. For example, 10 day period would be
great!

And when BETA/RC time comes users rush like mad to test it. And they find
errors and bugs. Writing PR, emails and even !pathes!
But the lion's share of these pathes doesn't get into the coming BETA or RC.
Maintainers say I don't have time [to test it] or It's too late.
Why is it late? I'm talking about only BUGS (PRs with pathes), not new
features. Let's users test it! In coming BETA/RC. Where are we in a hurry?
The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the only
purpose of it.
Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE.
Because of this situation most people says x.0 RELASE isn't for
production.

All the above applies only to the opening of a new STABLE branch, 9 for this
time.
I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be
longer. Six months, for example.
New STABLE branch is very important!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] hostap mode fixes with ath(4)

[Pavel Timofeev]

I can't beleive! Can't reproduce it!
I just gets sometimes ath0: stuck beacon; resetting (bmiss count 4)
messages and nothing else.
But now almost wlan channels doesn't loaded with other APs.
=(

2011/9/29 Adrian Chadd adr...@freebsd.org

 On 29 September 2011 19:58, Pavel Timofeev tim...@gmail.com wrote:

  Would you mind getting a log of the numbers given to you after
  'hardware error; resetting' ? please?
 
   I don't remember. But I can go back to 8.2 RELEASE and get it.

 I'd appreciate it if you could, please.

 Thanks,


 Adrian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] hostap mode fixes with ath(4)

[Pavel Timofeev]

2011/9/29 Adrian Chadd adr...@freebsd.org

 Hi!


 So you're saying that my code behaves better? :-)

Yes, I am! =)


 Would you mind getting a log of the numbers given to you after
 'hardware error; resetting' ? please?

 I don't remember. But I can go back to 8.2 RELEASE and get it.




 Adrian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: em problem in virtualbox since the weekend

[Pavel Timofeev]

Hmm, it was a few days ago.
Something like Unable to allocate bus resource: memory

Today I rebuilt latest kernel  world and now em and ahci works!

2011/7/25 John Baldwin j...@freebsd.org

 On Monday, July 25, 2011 6:46:44 am timp wrote:
  I have same problems with em and ahci.
 
  Now in VirtialBox I temporarily set net iface to PCNet-PCI II
 (Am79C970A).
  It works with if_le driver.
 
  VirtualBox 4.1, recent FreeBSD 9.

 So are you having problems with the latest FreeBSD 9?  Can you capture a
 verbose dmesg if so?

 --
 John Baldwin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org