Re: kernel reordering and config -e

[Sebastien Marie]

On Sun, Nov 19, 2017 at 10:19:05PM -0800, Paul B. Henson wrote:
> On Mon, Nov 20, 2017 at 06:50:30AM +0100, Sebastien Marie wrote:
> 
> > For me, there is currently no way to ask config(8) to alter the right
> > file in /usr/share/relink/kernel to "ship" the modification in all
> > future generated KARL kernels.
> 
> I thought that might be the case; maybe someday config(8) will be
> extended to work with the object files as well as the kernel binary
> itself to allow that.

I think it should be possible, but it isn't trivial to implement as it
is a binary editing. It needs to locate proper offset of a symbol inside
ELF file, and make changes.

> > - makes your changes in /usr/src/sys, build and install a new no-GENERIC
> >   kernel (and do it at each upgrade)
> 
> If I do that, can the resultant object files (which will have my com2
> irq change) be used with KARL? Hmm, it seems like all I really need to
> do is compile a new com_isa.o and drop it in to the existing directory?
> Or replace whichever object file contains the constant I need to change;
> it's not like I'm modifying code or making any drastic changes... Hmm,

As long you use standard "make install" to install the kernel, it will
do all the stuff for you: installing the /bsd file and generating KARL
files for the next boot.

> I'll have to compile a new kernel and poke at it; it'll just be a matter
> of remembering to redo it after patches, but I already had to redo the
> config -e anyway.

I use config(8) for some hosts using cupsd with usb printers, so I need
to do config(8) stuff each time I upgrade (disabling ulpt(4)). It could
be easily instrumented in /upgrade.site.

Recompiling a kernel is a more complex task, not really doable in
/upgrade.site.

-- 
Sebastien Marie

Sierra Wireless MC7455 LTE cell network card

[Paul B. Henson]

I'm trying to get the subject card to work under OpenBSD 6.2; it works
fine under Linux so I know the card itself and its SIM etc are correctly
configured and functional.

The card is set to MBIM mode, and I'd like to use the umb driver rather
than the umsm driver as not to have to muck with PPP. It seems this card
is detected first by the umsm driver though, as I had to disable that
driver for the card to be picked up by umb. The umb man page says
"Devices which fail to provide a conforming MBIM implementation will
probably be attached as some other driver", does this indicate the
MC7455 (as opposed to the EM7455, which is explicitly listed as
compatible) isn't recognized as an MBIM device? It seems to work fine in
MBIM mode under linux, and the umb driver does find it once umsm is
disabled.

Is there any way to access the serial interface of the device under
openbsd in order to execute diagostic AT commands? Under linux in
addition to the network device the card also generates a few USB serial
devices, one of which can be used to run commands on it. I saw such
devices with the umsm driver, but I don't see any with the umb driver. I
haven't gotten any farther than installing the card and getting the umb
driver to recognize it at this point, but it would be nice to be able to
poke at it and see what the card has to say for itself.

Thanks...

Re: kernel reordering and config -e

[Paul B. Henson]

On Mon, Nov 20, 2017 at 06:50:30AM +0100, Sebastien Marie wrote:

> When it did that, it uses the object (I didn't recall the exact name)
> with the previous mentioned array, with *default* configuration. So the
> previous modification done with config(8) is cleared.

Yeah, I figured that out after I updated the saved KARL hash and then my
box came up with no serial console :).

> For me, there is currently no way to ask config(8) to alter the right
> file in /usr/share/relink/kernel to "ship" the modification in all
> future generated KARL kernels.

I thought that might be the case; maybe someday config(8) will be
extended to work with the object files as well as the kernel binary
itself to allow that.

> - makes your changes in /usr/src/sys, build and install a new no-GENERIC
>   kernel (and do it at each upgrade)

If I do that, can the resultant object files (which will have my com2
irq change) be used with KARL? Hmm, it seems like all I really need to
do is compile a new com_isa.o and drop it in to the existing directory?
Or replace whichever object file contains the constant I need to change;
it's not like I'm modifying code or making any drastic changes... Hmm,
I'll have to compile a new kernel and poke at it; it'll just be a matter
of remembering to redo it after patches, but I already had to redo the
config -e anyway.

Thanks...

Re: kernel reordering and config -e

[Sebastien Marie]

On Sun, Nov 19, 2017 at 07:31:20PM -0800, Paul B. Henson wrote:
> I just updated a server to 6.2; unfortunately this box has an oddball
> SOL com2 on irq10 so I need to run 'config -e' on the kernel to update
> it and make the serial console work. I noticed afterwards in the boot
> messages it was complaining about kernel reordering failures, and
> thinking I was fixing it, I updated the file /var/db/kernel.SHA256 with
> the hash of my modified kernel. I quickly discovered that resulted in a
> successfully reordered kernel with a stock com2 irq :(.
> 
> I didn't see anything in the config man page or faq about interaction
> between kernel reordering and config on a binary kernel. In hindsight I
> see that the hash check is to keep from replacing a locally modified
> kernel.  Is there a supported way to both fix hardcoded settings on a
> stock kernel and use reordering? Or do you need to update your settings
> in the config and compile a kernel from scratch? If you do, does
> /usr/share/compile automatically get populated with your new kernel
> objects and reordering just starts working, or do you need to do
> something manually to get it running with a locally compiled kernel?
> 

config -e and KARL (kernel reordering) are mutually incompatibles.

By using config -e, you modify /bsd: config(8) did a binary change in a
particular array in the kernel file (in short, the one which contains
the list of drivers to load: it sets a bit to saying "disabled" for a
particular driver, for example).

KARL uses /usr/share/relink/kernel/*/*.o files to regenerate a new
kernel (and placing objects in random order). A new /bsd file is
generated using these objects.

When it did that, it uses the object (I didn't recall the exact name)
with the previous mentioned array, with *default* configuration. So the
previous modification done with config(8) is cleared.

For me, there is currently no way to ask config(8) to alter the right
file in /usr/share/relink/kernel to "ship" the modification in all
future generated KARL kernels.

So currently, you have to choose between:
- modifying /bsd with config(8) and don't benefice of KARL
- have KARL and using a default kernel
- makes your changes in /usr/src/sys, build and install a new no-GENERIC
  kernel (and do it at each upgrade)

Thanks.
-- 
Sebastien Marie

kernel reordering and config -e

[Paul B. Henson]

I just updated a server to 6.2; unfortunately this box has an oddball
SOL com2 on irq10 so I need to run 'config -e' on the kernel to update
it and make the serial console work. I noticed afterwards in the boot
messages it was complaining about kernel reordering failures, and
thinking I was fixing it, I updated the file /var/db/kernel.SHA256 with
the hash of my modified kernel. I quickly discovered that resulted in a
successfully reordered kernel with a stock com2 irq :(.

I didn't see anything in the config man page or faq about interaction
between kernel reordering and config on a binary kernel. In hindsight I
see that the hash check is to keep from replacing a locally modified
kernel.  Is there a supported way to both fix hardcoded settings on a
stock kernel and use reordering? Or do you need to update your settings
in the config and compile a kernel from scratch? If you do, does
/usr/share/compile automatically get populated with your new kernel
objects and reordering just starts working, or do you need to do
something manually to get it running with a locally compiled kernel?

Thanks...

Re: Not able to copy files to / from Android device

[Enric Morales]

 Venu Chakravorty  writes:
 >
 > I can't see any files in "./mnt". I was expecting to see the files from the 
 > Android device in "./mnt", but it is just empty. Please help. Is there any 
 > other way (other than using "simple-mtpfs") to do this?
 >
 > Thanks in advance.

 If you can't get simple-mtpfs to work, there are some
 alternatives. Besides the ones that you were suggested in other
 messages, I find that the most useful is sshfs. I use the "primitive
 ftpd" server, which also provides ftp. For its ssh server, I suggest you
 to try the fuse sshfs module, available in ports, and an ftp client. You
 then can choose which one is more appropriate for your use case. You can
 find primitive ftpd in f-droid.

 Cheers,

 Enric Morales 

Re: The "like" factor

[Rupert Gallagher]

Yes, this may well be the problem: easier to understand if we speak of teddy 
bear, much harder if we speak
of software upgrades! And yet, here we are...

Sent from ProtonMail Mobile

On Mon, Nov 20, 2017 at 02:17,  wrote:

> I wrote: > > In that case, I'd interpret the beancounter's reponse as 'have 
> to make > sacrifices, don't we? *sigh*'. I amend that. Isn't it just loss? We 
> experienced techies try not to allow ourselves to get too attached to an 
> environment, don't we? But hasn't there been a 'first time' this has 
> happened, for us all? And were *we* that prepared for it? It's like a 
> replacement teddy bear, isn't it? The old one might be in pieces and still 
> the new one won't ever feel as real. Or one's first love. It never quite 
> feels the same again, does it? Perhaps a shared drink to mark the transition 
> will help the grieving process along a little. I could still be all wrong, so 
> I'll just shut up for now and see what others have to say. --schaafuit.

Re: The "like" factor

[Rupert Gallagher]

LibreOffice has the *old* Microsoft Office GUI, which is what the users wanted. 
The change was introduced to help them keeping the old workflow with the old 
GUI while meeting the demands of automated software deployment, relevant ISO 
27001/2 policies, and yes, get past the Microsoft licencing nightmare. This is 
not a light-hearted change: it requires quite a bit of thinkwring with a 
sprinkle of courage.

Sent from ProtonMail Mobile

> @safe-mail.net>

RE: The "like" factor

[leo_tck]

I wrote:
>
> In that case, I'd interpret the beancounter's reponse as 'have to make
> sacrifices, don't we? *sigh*'.

I amend that.

Isn't it just loss?

We experienced techies try not to allow ourselves to get too attached
to an environment, don't we? But hasn't there been a 'first time' this
has happened, for us all? And were *we* that prepared for it?

It's like a replacement teddy bear, isn't it? The old one might be in
pieces and still the new one won't ever feel as real.

Or one's first love. It never quite feels the same again, does it?

Perhaps a shared drink to mark the transition will help the grieving
process along a little.

I could still be all wrong, so I'll just shut up for now and see what
others have to say.

--schaafuit.

Re: The "like" factor

[Rupert Gallagher]

Muscle memory and shortcuts are certainly something we must look after, within 
reason. Microsoft itself has changed menu one time too many, to the point of 
having people complain for it and not wanting to use the new versions. As they 
now have a menu that is close to the original favourite, and a modern engine 
underneath, perhaps we should circulate a DIY memo on menu icons relocation.

Sent from ProtonMail Mobile

On Mon, Nov 20, 2017 at 00:43, Noah  wrote:

> The software does mostly the same things, but you moved the menus and buttons 
> around. The pictures they recognize aren't there. Things work just a little 
> differently now. For some, it takes longer to do the things they need to do. 
> They have muscle memory and "shortcuts" that some of us find silly (such as 
> "I don't know what it's called, but it's always been the squiggly icon near 
> the top right corner" or "it's the third thing down on the second menu bar 
> list"). Chances are, the revolt would be similar upgrading from Win XP to 7, 
> 7 to 10, or office 97 to office 2012.
>
> Prepare to be very patient with them. Give them the training and resources 
> they need to get their workflows back. They just want to do their jobs, and 
> they don't care if you dislike the tools they've grown comfortable with.
>
> On Nov 19, 2017 4:44 PM, "Rupert Gallagher"  wrote:
>
>> We nerds are the other side of the problem, because we are apparently unable 
>> to understand their problem. We have little simpathy for those who frown 
>> without evidence of an actual problem. Perhaps this is an example that 
>> humans still find it comfortable to "follow and go along together", like a 
>> herd of sheeps. Since "word" and "excel" is what they hear and use, perhaps 
>> they feel "cheap" or "non-standard" by using something else. Perhaps all we 
>> need to do with libreoffice is to improve its spash-screen, its icons and 
>> menus, and they will never notice the difference.
>>
>> Sent from ProtonMail Mobile

Re: Current #197 Nov 5 umb0 ucom0 umodem0 detached.

[tinkr]

Ah right, the bug actually trigs below, so this is the XHCI_DEBUG log for the 
whole bug/failure sequence. Great.

> Thanks for your answer. Sorry for the delay.
> 
> In /cc to mpi@.
> 
>> The first thing I see when looking at your report, is that your USB
>> devices were plugged in via USB3 (XHCI).
> 
> It is a m.2 card in a ThinkPad. Yes, as it looks, they use USB3 internal.
> 
>> Please recompile your kernel with XHCI_DEBUG, and share the debug
>> output here (and with mpi@) when you have it, when the error happened
>> next time. Ok?
> 
> Build is done with the snapshot #220 from Nov 17 and the CVS from
> yesterday Nov 18 evening.
> 
> Off topic : for my understanding, I followed the FAQ for buiding a
> custom kernel and used GENERIC.MP instead of GENERIC because it is a
> multiprocessor machine. What is the difference of bsd and bsd.gdb what
> is shown at the end of the build ?
> 
> Output of /var/log/messages
> 
> Nov 18 23:32:47 thinkpad-w541 pkg_add: Added git-2.15.0
> Nov 19 00:00:01 thinkpad-w541 syslogd[73165]: restart
> Nov 19 05:11:27 thinkpad-w541 xlock: xlock: unable to open display .
> Nov 19 05:11:27 thinkpad-w541 xlock: Stop: root, wheel, unknown
> display, 0m 0s
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: port=10 change=0x00
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer:
> xfer=0xff087b6491e0 status=IN_PROGRESS err=CANCELLED actlen=0
> len=31744 idx=103
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 5
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped
> xfer=0xff087b6491e0
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
> dev 3 dci 5
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer:
> xfer=0xff087b6490f0 status=IN_PROGRESS err=CANCELLED actlen=0
> len=24 idx=13
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 3
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped
> xfer=0xff087b6490f0
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
> dev 3 dci 3
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
> Nov 19 13:51:44 thinkpad-w541 /bsd: umb0 detached
> Nov 19 13:51:44 thinkpad-w541 /bsd: ucom0 detached
> Nov 19 13:51:44 thinkpad-w541 /bsd: umodem0 detached
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
> Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7,
> input=0xff00022cc000 slot=0xff00022cc020
> ep0=0xff00022cc040
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7, setting DCBAA to
> 0x022cd000
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci_pipe_init:
> pipe=0x80fec000 addr=0 depth=1 port=10 speed=3 dev 7 dci 1
> (epAddr=0x0)
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=1
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=0
> Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7 addr 7
> Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_abort_xfer:
> xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=2
> idx=38
> Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1
> Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_event_xfer: stopped
> xfer=0xff087b6490f0
> Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
> dev 7 dci 1
> Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_abort_xfer:
> xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=0
> idx=40
> Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1
> Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_event_xfer: stopped
> xfer=0xff087b6490f0
> Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
> dev 7 dci 1
> Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: port 10, set config 0 at
> addr 4 failed
> Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 7
> Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
> Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: device problem, disabling
> port 10
> Nov 19 18:00:01 thinkpad-w541 syslogd[73165]: restart
> Nov 19 21:00:02 thinkpad-w541 syslogd[73165]: restart
> Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00
> Nov 19 22:24:32 thinkpad-w541 /bsd: ugen2 detached
> Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 4
> Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
> Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00
> Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00
> Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
> Nov 19 22:24:33 thinkpad-w541 /bsd: xhc

Re: The "like" factor

[bytevolcano]

On Mon, 20 Nov 2017 00:40:38 +0100
 wrote:

> bytevolc...@safe-mail.net wrote:
> > Perhaps it isn't just word/excel, but rather, getting used to the
> > operating system changes and its antics. It appears you have changed
> > their OS and their software, and this has upset them. No training
> > was provided explaining to them the nooks and crannies of the new
> > software, so they are frustrated as they are forced to satisfy
> > someone elses' nerdgasm.  
> 
> How is office politics necessarily equivalent to a 'nerdgasm'?

Think about this. You change the toolset they've been used to for
years, with something radically different. Whether or not you like it,
OpenOffice/Libreoffice/OpenBSD/Linux is radically different from a MS
Office/Windows setup. Now instead of coming to work and just doing the
job they were assigned to, they now have to learn new bits of software,
and you "don't understand the problem."

> Either way, aren't most 'desktop environments', and libreoffice,
> 'sold' on the premise that it's so easy to convert from M$ poop?


> Given the situation he described it was more like windoze nt 5.2. I
> could be wrong on that, though.

Doesn't matter. It appears he just forced his users to use radically
different software to do the same task, without understanding what they
face, or justifying his reason for the change to the users.

> Yeah, but like in most other abusive relationships, those people find
> it very hard to leave M$, whatever they do.
> 
> And will still eye a potential replacement partner with a lot of
> scepticism (not quite unjustified).

It won't help the case if you come across as unsympathetic/unwilling to
understand your users, and it won't help if you don't try to work with
them to resolve the issues.

This is the key to solving the "like" factor, as Rupert calls it. The
users rightfully want a justification for the change, and they won't
understand "oh this software is open source, so we're not locked in to
proprietary closed Microsoft software." They won't care either, they
just want to do the job and go home.

I don't do this kind of thing anymore, but whenever I had to change the
system around, some retraining was in order and I would provide the
user with a comparison on how they did something in the old system vs
how they do it in the new system.

RE: The "like" factor

[leo_tck]

"Rupert Gallagher"  wrote:
> Well, people hated Microsoft's new GUIs, and wanted the old windows xp/7 
> back, which we delivered. They are happy now, and so do we.
>
> They also hated the new GUI with the latest Office suite, so they kept using 
> the older version. LibreOffice has the Microsoft Office GUI, so they are 
> happy now, and so do we.
>
> The original file explorer has always been simple minded, and they are happy 
> to experiment with the alternatives.

In that case, I'd interpret the beancounter's reponse as 'have to make 
sacrifices, don't we? *sigh*'.

--schaafuit.

Re: The "like" factor

[Rupert Gallagher]

Well, people hated Microsoft's new GUIs, and wanted the old windows xp/7 back, 
which we delivered. They are happy now, and so do we.

They also hated the new GUI with the latest Office suite, so they kept using 
the older version. LibreOffice has the Microsoft Office GUI, so they are happy 
now, and so do we.

The original file explorer has always been simple minded, and they are happy to 
experiment with the alternatives.

Sent from ProtonMail Mobile

On Mon, Nov 20, 2017 at 00:29,  wrote:

> Perhaps it isn't just word/excel, but rather, getting used to the operating 
> system changes and its antics. It appears you have changed their OS and their 
> software, and this has upset them. No training was provided explaining to 
> them the nooks and crannies of the new software, so they are frustrated as 
> they are forced to satisfy someone elses' nerdgasm. I notice a big difference 
> between modern MS Office and LibreOffice/OpenOffice, which is why I prefer 
> the latter. I also notice a big difference between OpenBSD and Windows 10, 
> and you would have to be a blithering idiot to not notice the differences. 
> You seem to have forgotten the huge uproar Microsoft created in 2006/2007 
> with the idiotic "ribbon" interface. This is similar, but on a much smaller, 
> more local scale.

RE: The "like" factor

[leo_tck]

bytevolc...@safe-mail.net wrote:
>
> Think about this. You change the toolset they've been used to for
> years, with something radically different. Whether or not you like it,
> OpenOffice/Libreoffice/OpenBSD/Linux is radically different from a MS
> Office/Windows setup. Now instead of coming to work and just doing the
> job they were assigned to, they now have to learn new bits of software,
> and you "don't understand the problem."

There's not necessarily any technical problem, at least not one that
cannot be solved (luser education has been mentioned).

But of course there's still a problem. If I'm not too mistaken, that's
why Rupert asked for advice.

> Doesn't matter. It appears he just forced his users to use radically
> different software to do the same task, without understanding what they
> face, or justifying his reason for the change to the users.

Yeah well, going by his wording, I divine that he was sceptical himself
and it was decided higher up the food chain.

I don't approve of it (and that's putting it mildly), but in some
organizations that's just how it works.

> It won't help the case if you come across as unsympathetic/unwilling to
> understand your users, and it won't help if you don't try to work with
> them to resolve the issues.

Well, if the root issue is the command from up high, then it's either
obey or quit. A nasty dilemma, to say the least.

> This is the key to solving the "like" factor, as Rupert calls it. The
> users rightfully want a justification for the change, and they won't
> understand "oh this software is open source, so we're not locked in to
> proprietary closed Microsoft software." They won't care either, they
> just want to do the job and go home.

Again, if it's you as a sysadmin that makes the decisions, that *can*
fly as well in practice as it does in theory.

But often you find yourself just obeying 'corporate policy', and it can
take a true BOFH to sabotage it effectively. 

> I don't do this kind of thing anymore, but whenever I had to change the
> system around, some retraining was in order and I would provide the
> user with a comparison on how they did something in the old system vs
> how they do it in the new system.

When some hyped geek sells it to the CEO, or (more likely) the higher
regions fall for the $$$ argument, and they have declared it "not
needed", well, what are you going to do?

Say that the shareholders can stuff the extra dividends up their asses?

Again, not everyone is a BOFH.

 --schaafuit.

RE: The "like" factor

[leo_tck]

"Daniel Wilkins"  wrote:
> Something to consider is that there *are* areas where libreoffice is 
> deficient.

Yup.

>
> It's not uncommon for businesses to have a terrifying amount of embedded 
> visual
> basic and incredibly elaborate excel macros, I wouldn't be surprised if the
> (possibly theoretical) suit literally can't get their work done because they
> don't have access to their scripts and macros that some secretary wrote in
> 1999. Any migration which messes with office, if you want it to be successful
> you really need a serious period of testing where you grab up as many
> business-essential documents as you can and identifying scripts and macros
> which may become problems, then rewriting them in LO compatible way (LO
> has scripting, it's just not *literally* vbscript). It has a basic dialect
> so translation shouldn't necessarily be hard, just time consuming.

I'd like to shoot the person who first decided that documents should
contain arbitrary macros (can we really call them that way, as it's
imperative? I associated macros with a declarative style) that varies
their contents.

But indeed, that doesn't help anyone who's made the unwise decision
to do so, at least not anymore. Their stuff will break, guaranteed.

Though repeating the mistake by re-writing stuff in yet another
'macro' language, embedded in documents, is something that I'd rather
see avoided.

--schaafuit.

Re: The "like" factor

[Daniel Wilkins]

Something to consider is that there *are* areas where libreoffice is deficient.

It's not uncommon for businesses to have a terrifying amount of embedded visual
basic and incredibly elaborate excel macros, I wouldn't be surprised if the
(possibly theoretical) suit literally can't get their work done because they
don't have access to their scripts and macros that some secretary wrote in
1999. Any migration which messes with office, if you want it to be successful
you really need a serious period of testing where you grab up as many
business-essential documents as you can and identifying scripts and macros
which may become problems, then rewriting them in LO compatible way (LO
has scripting, it's just not *literally* vbscript). It has a basic dialect
so translation shouldn't necessarily be hard, just time consuming.

RE: The "like" factor

[leo_tck]

"Noah"  wrote:
> The software does mostly the same things, but you moved the menus and
> buttons around. The pictures they recognize aren't there. Things work just
> a little differently now. For some, it takes longer to do the things they
> need to do. They have muscle memory and "shortcuts" that some of us find
> silly (such as "I don't know what it's called, but it's always been the
> squiggly icon near the top right corner" or "it's the third thing down on
> the second menu bar list"). Chances are, the revolt would be similar
> upgrading from Win XP to 7, 7 to 10, or office 97 to office 2012.
>
> Prepare to be very patient with them. Give them the training and resources
> they need to get their workflows back. They just want to do their jobs, and
> they don't care if you dislike the tools they've grown comfortable with.

You're looking at it from a purely technical perspective. I'm not sure
that's justified, given all the potential social causes Rupert and I
just identified. 

Besides, despite all technical measures, you can't make people like
something.

Except of course with application of the hungry doberman and the length
of rubber hose...

--schaafuit.

Re: SPOOFED: Re: The "like" factor

[bytevolcano]

Perhaps it isn't just word/excel, but rather, getting used to the
operating system changes and its antics. It appears you have changed
their OS and their software, and this has upset them. No training was
provided explaining to them the nooks and crannies of the new software,
so they are frustrated as they are forced to satisfy someone elses'
nerdgasm.

I notice a big difference between modern MS Office and
LibreOffice/OpenOffice, which is why I prefer the latter. I also notice
a big difference between OpenBSD and Windows 10, and you would have to
be a blithering idiot to not notice the differences.

You seem to have forgotten the huge uproar Microsoft created in
2006/2007 with the idiotic "ribbon" interface. This is similar, but on
a much smaller, more local scale.

On Sun, 19 Nov 2017 17:44:06 -0500
Rupert Gallagher  wrote:

> We nerds are the other side of the problem, because we are apparently
> unable to understand their problem. We have little simpathy for those
> who frown without evidence of an actual problem. Perhaps this is an
> example that humans still find it comfortable to "follow and go along
> together", like a herd of sheeps. Since "word" and "excel" is what
> they hear and use, perhaps they feel "cheap" or "non-standard" by
> using something else. Perhaps all we need to do with libreoffice is
> to improve its spash-screen, its icons and menus, and they will never
> notice the difference.
> 
> Sent from ProtonMail Mobile

FU: RE: The "like" factor

[leo_tck]

I wrote:
> windoze nt 5.2.

I meant 6.0. Sorry, haven't been keeping track and M$ is, true to
form, not making it easy by having obscured the number (and since
having switched to outright *lying* about it).

--schaafuit.

RE: The "like" factor

[leo_tck]

bytevolc...@safe-mail.net wrote:
> Perhaps it isn't just word/excel, but rather, getting used to the
> operating system changes and its antics. It appears you have changed
> their OS and their software, and this has upset them. No training was
> provided explaining to them the nooks and crannies of the new software,
> so they are frustrated as they are forced to satisfy someone elses'
> nerdgasm.

How is office politics necessarily equivalent to a 'nerdgasm'?

Either way, aren't most 'desktop environments', and libreoffice, 'sold'
on the premise that it's so easy to convert from M$ poop?

> I notice a big difference between modern MS Office and
> LibreOffice/OpenOffice, which is why I prefer the latter. I also notice
> a big difference between OpenBSD and Windows 10, and you would have to
> be a blithering idiot to not notice the differences.

Given the situation he described it was more like windoze nt 5.2. I
could be wrong on that, though.

> You seem to have forgotten the huge uproar Microsoft created in
> 2006/2007 with the idiotic "ribbon" interface. This is similar, but on
> a much smaller, more local scale.

Yeah, but like in most other abusive relationships, those people find it
very hard to leave M$, whatever they do.

And will still eye a potential replacement partner with a lot of
scepticism (not quite unjustified).

--schaafuit.

P.S.: why 'SPOOFED'?

RE: The "like" factor

[leo_tck]

"Rupert Gallagher"  rote:
> We nerds are the other side of the problem, because we are apparently unable 
> to understand their problem.

And even if we understand it, we often cannot offer a solution that
satisfies them.

> We have little simpathy for those who frown without evidence of an actual 
> problem.

The flip side of this is that a feeling sometimes *is* a good indicator
that there's something wrong, without being able to consciously define
that 'something'.

> Perhaps this is an example that humans still find it comfortable to
> "follow and go along together", like a herd of sheeps.

If that's all they've ever known...

> Since "word" and "excel" is what they hear and use, perhaps they feel
> "cheap" or "non-standard" by using something else.

IME that attitude goes from politics all the way down to underwear. 

> Perhaps all we need to do with libreoffice is to improve its
> spash-screen, its icons and menus, and they will never notice the
> difference.

Yeah well, gnome, kde, et al certainly appear to follow the 'IBM CUA'
approach: a grand unified set of rules, determined through extensive
pseudo-scientific research... resulting in an appearance that only a
mother could love :)

I might be wrong, though. I don't use those.

--schaafuit.

Re: The "like" factor

[Rupert Gallagher]

We nerds are the other side of the problem, because we are apparently unable to 
understand their problem. We have little simpathy for those who frown without 
evidence of an actual problem. Perhaps this is an example that humans still 
find it comfortable to "follow and go along together", like a herd of sheeps. 
Since "word" and "excel" is what they hear and use, perhaps they feel "cheap" 
or "non-standard" by using something else. Perhaps all we need to do with 
libreoffice is to improve its spash-screen, its icons and menus, and they will 
never notice the difference.

Sent from ProtonMail Mobile

RE: The "like" factor

[leo_tck]

Hi,

"Rupert Gallagher"  wrote:
> How did you solve the "like" factor?

As I have no experience in office situations, I cannot answer that.

However, it would've been an interesting experiment to just swap the
logos and see how long it'd take for them to notice.

#include 

Hm, that makes me recall a dark and distant past in which I preferred
the look of windoze 3 over any other WIMPy GUI I had seen, even though
it was the least useful of 'em all, and in hindsight is certainly one of
the ugliest.

I was a little kid at the time. I suppose I was just not mature enough
to appreciate alternatives to what I'd been given. Besides, I had (and
still have) little use for WIMPy GUIs. As now, I mainly used them for
games that I like but are so broken that they will only run under them. 

And beancounters hate 'scruffies', not to forget, and that hate tends to
be mutual. Using something associated with an opposing tribe is
something that primates tend to rather frown upon.

If the beancounter was of the somewhat more mature variety, his
disappointment may just have been an 'it was nice while it lasted, but
we all have to grow up' type of reaction, though. I couldn't possibly
judge this.

If none of these explanations apply, I guess it's plain familiarity.

Or the groupthink that primates are well-known for.

--schaafuit.

Re: Current #197 Nov 5 umb0 ucom0 umodem0 detached.

[Christoph R. Murauer]

Thanks for your answer. Sorry for the delay.

In /cc to mpi@.

> The first thing I see when looking at your report, is that your USB
> devices were plugged in via USB3 (XHCI).

It is a m.2 card in a ThinkPad. Yes, as it looks, they use USB3 internal.

> Please recompile your kernel with XHCI_DEBUG, and share the debug
> output here (and with mpi@) when you have it, when the error happened
> next time. Ok?

Build is done with the snapshot #220 from Nov 17 and the CVS from
yesterday Nov 18 evening.

Off topic : for my understanding, I followed the FAQ for buiding a
custom kernel and used GENERIC.MP instead of GENERIC because it is a
multiprocessor machine. What is the difference of bsd and bsd.gdb what
is shown at the end of the build ?

Output of /var/log/messages

Nov 18 23:32:47 thinkpad-w541 pkg_add: Added git-2.15.0
Nov 19 00:00:01 thinkpad-w541 syslogd[73165]: restart
Nov 19 05:11:27 thinkpad-w541 xlock: xlock: unable to open display .
Nov 19 05:11:27 thinkpad-w541 xlock: Stop: root, wheel, unknown
display, 0m 0s
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: port=10 change=0x00
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer:
xfer=0xff087b6491e0 status=IN_PROGRESS err=CANCELLED actlen=0
len=31744 idx=103
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 5
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped
xfer=0xff087b6491e0
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
dev 3 dci 5
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_abort_xfer:
xfer=0xff087b6490f0 status=IN_PROGRESS err=CANCELLED actlen=0
len=24 idx=13
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 3 dci 3
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci_event_xfer: stopped
xfer=0xff087b6490f0
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
dev 3 dci 3
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
Nov 19 13:51:44 thinkpad-w541 /bsd: umb0 detached
Nov 19 13:51:44 thinkpad-w541 /bsd: ucom0 detached
Nov 19 13:51:44 thinkpad-w541 /bsd: umodem0 detached
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 3
Nov 19 13:51:44 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: port=10 change=0x00
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7,
input=0xff00022cc000 slot=0xff00022cc020
ep0=0xff00022cc040
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7, setting DCBAA to
0x022cd000
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci_pipe_init:
pipe=0x80fec000 addr=0 depth=1 port=10 speed=3 dev 7 dci 1
(epAddr=0x0)
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=1
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_address BSR=0
Nov 19 13:51:50 thinkpad-w541 /bsd: xhci0: dev 7 addr 7
Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_abort_xfer:
xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=2
idx=38
Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1
Nov 19 13:51:55 thinkpad-w541 /bsd: xhci_event_xfer: stopped
xfer=0xff087b6490f0
Nov 19 13:51:55 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
dev 7 dci 1
Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_abort_xfer:
xfer=0xff087b6490f0 status=IN_PROGRESS err=TIMEOUT actlen=0 len=0
idx=40
Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_stop_ep dev 7 dci 1
Nov 19 13:52:00 thinkpad-w541 /bsd: xhci_event_xfer: stopped
xfer=0xff087b6490f0
Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_set_tr_deq_async
dev 7 dci 1
Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: port 10, set config 0 at
addr 4 failed
Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 7
Nov 19 13:52:00 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
Nov 19 13:52:00 thinkpad-w541 /bsd: uhub0: device problem, disabling
port 10
Nov 19 18:00:01 thinkpad-w541 syslogd[73165]: restart
Nov 19 21:00:02 thinkpad-w541 syslogd[73165]: restart
Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00
Nov 19 22:24:32 thinkpad-w541 /bsd: ugen2 detached
Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_configure_ep dev 4
Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00
Nov 19 22:24:32 thinkpad-w541 /bsd: xhci0: port=11 change=0x00
Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: xhci_cmd_slot_control
Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: dev 8,
input=0xff00676d4000 slot=0xff00676d4020
ep0=0xff00676d4040
Nov 19 22:24:33 thinkpad-w541 /bsd: xhci0: dev 8, setting DCBAA to
0x676d5000
Nov 19 22:24:33 thinkpad-w541 /bsd: xhci_pipe_init:
pipe=0x80fec000 addr=0 depth=1 port=11 speed=2 dev 8 dci 1
(epAddr=0x0)
Nov 19 

Re: Not able to copy files to / from Android device

[Stephane HUC "PengouinBSD"]

Le 11/19/17 à 22:21, Stuart Henderson a écrit :
> On 2017-11-19, Venu Chakravorty  wrote:
>> Hello there,
>> I am trying to copy files to / form my android device using "simple-mtpfs". 
>> However, I am not able to mount the file system of the Android device. On 
>> the phone, the "Media Device (MTP)" check-box is checked. The following is 
>> what I have tried:
>>
>> $ mkdir mnt
>> $ simple-mtpfs -l
>>   
>> 1: MotorolaMoto G (ID2)
>> $ simple-mtpfs --device 1 ./mnt
>> $ ls ./mnt
>> $ 
>>
>> I can't see any files in "./mnt". I was expecting to see the files from the 
>> Android device in "./mnt", but it is just empty. Please help. Is there any 
>> other way (other than using "simple-mtpfs") to do this?
> 
> This might not be the only problem, but you at least need to be root
> to mount.

:D

Just, to use adb, it's not need to be root, only as user!


~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net

Re: Not able to copy files to / from Android device

[Stuart Henderson]

On 2017-11-19, Venu Chakravorty  wrote:
> Hello there,
> I am trying to copy files to / form my android device using "simple-mtpfs". 
> However, I am not able to mount the file system of the Android device. On the 
> phone, the "Media Device (MTP)" check-box is checked. The following is what I 
> have tried:
>
> $ mkdir mnt
> $ simple-mtpfs -l 
>  
> 1: MotorolaMoto G (ID2)
> $ simple-mtpfs --device 1 ./mnt
> $ ls ./mnt
> $ 
>
> I can't see any files in "./mnt". I was expecting to see the files from the 
> Android device in "./mnt", but it is just empty. Please help. Is there any 
> other way (other than using "simple-mtpfs") to do this?

This might not be the only problem, but you at least need to be root
to mount.

The "like" factor

[Rupert Gallagher]

I bet none of you dared this much in "change management". The accountant walks 
in to a new work-station. The initial excitement is followed by a quiet "no 
windows 10/7/xp? and a less quiet "no windows office?". That's right: new 
office politics, we are through with Microsoft, move on with your duties. All 
is well, apart from the "like" factor. The user is unable to explain why they 
miss Microsoft Excell and Word 2007, by comparison with up-to-date libreoffice.

How did you solve the "like" factor?

Sent from ProtonMail Mobile

Re: Not able to copy files to / from Android device

[Stephane HUC "PengouinBSD"]

Hi, Venu

First, see into this page, if your android device is recognized:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/usb/usbdevs

If yes, after, you can attempt to use directly adb tool ;)

=> install adb

Check if your device is really recognized:

=> adb devices

If adb result as:

$ adb devices
List of devices attached
0123456789ABCDEF  device

is good!

To copy from computer to android, use:

=> adb push -p /dir_into_computer/file /dir_into_android

To copy from android to computer, use:

=> adb pull -a -p /dir_into_android/file /dir_into_computer

Assume directories exists! ;)



Enjoy-IT!
Enjoy-ID!


Le 11/19/17 à 19:19, Venu Chakravorty a écrit :
> Hello there,
> I am trying to copy files to / form my android device using "simple-mtpfs". 
> However, I am not able to mount the file system of the Android device. On the 
> phone, the "Media Device (MTP)" check-box is checked. The following is what I 
> have tried:
> 
> $ mkdir mnt
> $ simple-mtpfs -l 
>  
> 1: MotorolaMoto G (ID2)
> $ simple-mtpfs --device 1 ./mnt
> $ ls ./mnt
> $ 
> 
> I can't see any files in "./mnt". I was expecting to see the files from the 
> Android device in "./mnt", but it is just empty. Please help. Is there any 
> other way (other than using "simple-mtpfs") to do this?
> 
> Thanks in advance.
> 

-- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net

Not able to copy files to / from Android device

[Venu Chakravorty]

Hello there,
I am trying to copy files to / form my android device using "simple-mtpfs". 
However, I am not able to mount the file system of the Android device. On the 
phone, the "Media Device (MTP)" check-box is checked. The following is what I 
have tried:

$ mkdir mnt
$ simple-mtpfs -l   
   
1: MotorolaMoto G (ID2)
$ simple-mtpfs --device 1 ./mnt
$ ls ./mnt
$ 

I can't see any files in "./mnt". I was expecting to see the files from the 
Android device in "./mnt", but it is just empty. Please help. Is there any 
other way (other than using "simple-mtpfs") to do this?

Thanks in advance.

Re: Radeon discrete graphics issues

[Timothy Legge]

I knew the solution would be something simple, more than likely related to
my inability to read properly :D
Thanks for the pointers Jonathan, sorry it took a while for the point to
stick.

I guess the next natural question is, can I put my hardware to use helping
develop support for this?
I'm no programmer, but I can be a test subject for others working on this.
And is it worth installing -current and sending the developers the dmesg
for reference? I've just realised I've only ever been running -stable on
this box.

On 19 November 2017 at 09:26, Jonathan Gray  wrote:

> There is kernel support for the initial GCN parts
> (CAPE VERDE, PITCAIRN, TAHITI) acceleration for those requires userland
> changes.  The last generation with full acceleration is Northern Islands.
>
> On Sun, Nov 19, 2017 at 09:04:40AM +, Timothy Legge wrote:
> > So after re-reading man pages and a quick consultation of some Wikipedia
> > pages, kernel support for most Radeon cards upto those in the Northern
> > Islands family are supported. That ties in nicely with what you've
> outlined
> > as thats the family that came before they made the change to the GCN
> > Microarchitecture and Instruction set.
> >
> > Hopefully it's something that will be supported in the not too distant
> > future.Until then, it's back in my box.
> >
> > Thanks all.
> >
> > On 19 November 2017 at 01:34, Jonathan Gray  wrote:
> >
> > > The userland driver that page describes won't work without kernel
> support.
> > >
> > > For GCN parts like OLAND it is worse as they require Mesa to be built
> > > against LLVM libraries for 2D acceleration.  And LLVM
> libraries/llvm-config
> > > etc are not built/shipped in base.
> > >
> > > On Sun, Nov 19, 2017 at 01:16:19AM +, Timothy Legge wrote:
> > > > I copy/pasted "OLAND Radeon HD 8000 series" from the radeon(4)
> > > >  man page under the section header
> > > > "Supported Hardware". Maybe I'm missing something.
> > > >
> > > > On 19 November 2017 at 01:08, Jonathan Gray  wrote:
> > > >
> > > > > On Sat, Nov 18, 2017 at 07:43:03PM +, Timothy Legge wrote:
> > > > > > @Maurice, Don't worry about teaching me to suck eggs, I'd rather
> > > cover
> > > > > all
> > > > > > the bases :)
> > > > > >
> > > > > > I've run "fw_update -a"  to ensure that the drivers are
> installed and
> > > > > where
> > > > > > they need to be. (Bit overkill I know, but I'd rather be sure at
> this
> > > > > > point.)
> > > > > > As for support from the Radeon driver as linked above, it falls
> > > under the
> > > > > > "OLAND Radeon HD 8000 series".
> > > > >
> > > > > The radeon code in the kernel is derived from Linux 3.8, support
> for
> > > > > the OLAND family wasn't added till 3.9.
> > > > >
> > > > > > It's almost as though the kernel forgets to add "radeondrm0 at
> vga1"
> > > and
> > > > > > "drm0 at radeondrm0" as seen on other dmesg from systems with
> Radeon
> > > > > cards.
> > > > > > I can't help shake the sense that the fix to this is going to be
> > > > > something
> > > > > > rather simple, and I'm just too stupid to figure it out! :)
> > > > > >
> > > > > > On 18 November 2017 at 19:14, Maurice McCarthy <
> mansel...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > I assume the radeon firmware is in /etc/firmware. If not
> download
> > > > > > > http://firmware.openbsd.org/firmware/6.2/radeondrm-
> > > > > firmware-20150927.tgz
> > > > > > > and untar it in that directory. (Sorry if I'm teaching granny
> to
> > > suck
> > > > > > > eggs.)
> > > > > > >
> > > > > > >
> > > > > > >  > > > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > > > Virus-free.
> > > > > > > www.avast.com
> > > > > > >  > > > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > > > >
> > > > >
> > >
>

Re: Transition from machdep.lidsuspend to machdep.lidaction?

[Karl]

Thank you! :)


So, the 6.0 -> 6.1 guide incorrectly refers to the sysctl setting as 
renamed, but at
that point they actually do co-exist, and therefore both work until 
upgrade to 6.2.


Maybe the 6.2 announcement/upgrade guide should have a list of settings 
that has actually been replaced/removed. That is at least how I'm used 
to reading  documentation/announcements.


Maybe I'm just being overly meticulous, but I have found many small 
things like this creating lots of confusing about OpenBSD :)




//Karl





On 11/19/17 00:59, Theo Buehler wrote:

On Sat, Nov 18, 2017 at 09:47:41PM +0100, pledge wrote:

Hello

I just upgraded my laptop 6.1 -> 6.2.

Suddenly it appears that the sysctl setting machdep.lidsuspend was gone.

I checked the whats new site https://www.openbsd.org/62.html and
https://www.openbsd.org/faq/upgrade62.html but found no information there.
Interestingly, on https://www.openbsd.org/faq/upgrade61.html there is this
note:

"*sysctl machdep.lidsuspend renamed to machdep.lidaction.* The
machdep.lidsuspend sysctl variable has been renamed to machdep.lidaction.
Setting it to 2 hibernates the machine when the lid is closed. Update
sysctl.conf(5)  to use
the new name."

So it appears that this note was on the wrong page? Since I was using it on
6.1 it can't have been renamed.

It was deprecated during the 6.1 release cycle

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c#rev1.224

and accordingly, its deprecation was announced on upgrade61.html. The
machdep.lidsuspend sysctl was left functioning to ease the transition.

During the 6.2 release cycle it was definitely removed:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c#rev1.231


Also, where can I find documentation about what more options there are to
machdep.lidaction?

The machdep sysctls are only briefly explained in comments in
/etc/examples/sysctl.conf, as sysctl(3) is already very long.

Here are the machdep sysctls for amd64:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/etc.amd64/sysctl.conf?annotate=1.7

Re: Radeon discrete graphics issues

[Jonathan Gray]

There is kernel support for the initial GCN parts
(CAPE VERDE, PITCAIRN, TAHITI) acceleration for those requires userland
changes.  The last generation with full acceleration is Northern Islands.

On Sun, Nov 19, 2017 at 09:04:40AM +, Timothy Legge wrote:
> So after re-reading man pages and a quick consultation of some Wikipedia
> pages, kernel support for most Radeon cards upto those in the Northern
> Islands family are supported. That ties in nicely with what you've outlined
> as thats the family that came before they made the change to the GCN
> Microarchitecture and Instruction set.
> 
> Hopefully it's something that will be supported in the not too distant
> future.Until then, it's back in my box.
> 
> Thanks all.
> 
> On 19 November 2017 at 01:34, Jonathan Gray  wrote:
> 
> > The userland driver that page describes won't work without kernel support.
> >
> > For GCN parts like OLAND it is worse as they require Mesa to be built
> > against LLVM libraries for 2D acceleration.  And LLVM libraries/llvm-config
> > etc are not built/shipped in base.
> >
> > On Sun, Nov 19, 2017 at 01:16:19AM +, Timothy Legge wrote:
> > > I copy/pasted "OLAND Radeon HD 8000 series" from the radeon(4)
> > >  man page under the section header
> > > "Supported Hardware". Maybe I'm missing something.
> > >
> > > On 19 November 2017 at 01:08, Jonathan Gray  wrote:
> > >
> > > > On Sat, Nov 18, 2017 at 07:43:03PM +, Timothy Legge wrote:
> > > > > @Maurice, Don't worry about teaching me to suck eggs, I'd rather
> > cover
> > > > all
> > > > > the bases :)
> > > > >
> > > > > I've run "fw_update -a"  to ensure that the drivers are installed and
> > > > where
> > > > > they need to be. (Bit overkill I know, but I'd rather be sure at this
> > > > > point.)
> > > > > As for support from the Radeon driver as linked above, it falls
> > under the
> > > > > "OLAND Radeon HD 8000 series".
> > > >
> > > > The radeon code in the kernel is derived from Linux 3.8, support for
> > > > the OLAND family wasn't added till 3.9.
> > > >
> > > > > It's almost as though the kernel forgets to add "radeondrm0 at vga1"
> > and
> > > > > "drm0 at radeondrm0" as seen on other dmesg from systems with Radeon
> > > > cards.
> > > > > I can't help shake the sense that the fix to this is going to be
> > > > something
> > > > > rather simple, and I'm just too stupid to figure it out! :)
> > > > >
> > > > > On 18 November 2017 at 19:14, Maurice McCarthy 
> > > > wrote:
> > > > >
> > > > > > I assume the radeon firmware is in /etc/firmware. If not download
> > > > > > http://firmware.openbsd.org/firmware/6.2/radeondrm-
> > > > firmware-20150927.tgz
> > > > > > and untar it in that directory. (Sorry if I'm teaching granny to
> > suck
> > > > > > eggs.)
> > > > > >
> > > > > >
> > > > > >  > > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > > Virus-free.
> > > > > > www.avast.com
> > > > > >  > > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > > >
> > > >
> >

mpd not opening port 8000 for streaming

[msv]

Hi misc I have been trying to stream audio via mpd to my smartphone
(with mpdroid) without success. I can't see the port 8000 open on
netstat, port 6600 for remote control is working fine. I don't know if
its related but vorbis encoder isn't working for me.


mpd.log and mpd.conf

===
mpd.log
===
Nov 19 09:38 : state_file: Loading state file /var/spool/mpd/mpdstate
Nov 19 09:38 : playlist: queue song 2:"warcry/2002- - WarCry/03 - Quiero.mp3"
Nov 19 09:38 : decoder_thread: probing plugin ffmpeg
Nov 19 09:38 : ffmpeg: detected input format 'mp3' (MP2/3 (MPEG audio layer 
2/3))
Nov 19 09:38 : ffmpeg/mp3: id3v2 ver:3 flags:00 len:70589
Nov 19 09:38 : ffmpeg/mp3: Skipping 0 bytes of junk at 70599.
Nov 19 09:38 : ffmpeg/mp3: Before avformat_find_stream_info() pos: 70599 bytes 
read:76263 seeks:0
Nov 19 09:38 : ffmpeg/mjpeg: marker=d8 avail_size_in_buf=67818
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 0 bytes (0 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=e0 avail_size_in_buf=67816
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 16 bytes (128 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=e2 avail_size_in_buf=67798
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 4055 bytes (32440 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=e1 avail_size_in_buf=63740
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 4279 bytes (34232 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=e1 avail_size_in_buf=59458
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 2666 bytes (21328 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=db avail_size_in_buf=56789
Nov 19 09:38 : ffmpeg/mjpeg: index=0
Nov 19 09:38 : ffmpeg/mjpeg: qscale[0]: 1
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 67 bytes (536 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=db avail_size_in_buf=56720
Nov 19 09:38 : ffmpeg/mjpeg: index=1
Nov 19 09:38 : ffmpeg/mjpeg: qscale[1]: 1
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 67 bytes (536 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=c0 avail_size_in_buf=56651
Nov 19 09:38 : ffmpeg/mjpeg: Changeing bps to 8
Nov 19 09:38 : ffmpeg/mjpeg: sof0: picture: 500x500
Nov 19 09:38 : ffmpeg/mjpeg: component 0 2:2 id: 0 quant:0
Nov 19 09:38 : ffmpeg/mjpeg: component 1 1:1 id: 1 quant:1
Nov 19 09:38 : ffmpeg/mjpeg: component 2 1:1 id: 2 quant:1
Nov 19 09:38 : ffmpeg/mjpeg: pix fmt id 2200
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 17 bytes (136 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=c4 avail_size_in_buf=56632
Nov 19 09:38 : ffmpeg/mjpeg: class=0 index=0 nb_codes=12
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 31 bytes (248 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=c4 avail_size_in_buf=56599
Nov 19 09:38 : ffmpeg/mjpeg: class=1 index=0 nb_codes=251
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 181 bytes (1448 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=c4 avail_size_in_buf=56416
Nov 19 09:38 : ffmpeg/mjpeg: class=0 index=1 nb_codes=12
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 31 bytes (248 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=c4 avail_size_in_buf=56383
Nov 19 09:38 : ffmpeg/mjpeg: class=1 index=1 nb_codes=251
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 181 bytes (1448 bits)
Nov 19 09:38 : ffmpeg/mjpeg: escaping removed 278 bytes
Nov 19 09:38 : ffmpeg/mjpeg: marker=da avail_size_in_buf=56200
Nov 19 09:38 : ffmpeg/mjpeg: component: 0
Nov 19 09:38 : ffmpeg/mjpeg: component: 1
Nov 19 09:38 : ffmpeg/mjpeg: component: 2
Nov 19 09:38 : ffmpeg/mjpeg: marker parser used 55921 bytes (447366 bits)
Nov 19 09:38 : ffmpeg/mjpeg: marker=d9 avail_size_in_buf=0
Nov 19 09:38 : ffmpeg/mjpeg: decode frame unused 0 bytes
Nov 19 09:38 : ffmpeg/mp3: max_analyze_duration 500 reached at 5015510 
microseconds st:0
Nov 19 09:38 : ffmpeg/mp3: Estimating duration from bitrate, this may be 
inaccurate
Nov 19 09:38 : ffmpeg/mp3: 0: start_time: 0.000 duration: 4296.167
Nov 19 09:38 : ffmpeg/mp3: 1: start_time: -9223372036854.775 duration: 27.399
Nov 19 09:38 : ffmpeg/mp3: stream: start_time: 0.000 duration: 304.434 
bitrate=321 kb/s
Nov 19 09:38 : ffmpeg/mp3: After avformat_find_stream_info() pos: 274375 bytes 
read:281063 seeks:0 frames:195
Nov 19 09:38 : ffmpeg: codec 'mp3'
Nov 19 09:38 : decoder: audio_format=44100:16:2, seekable=true
Nov 19 09:38 : client: [0] opened from 192.168.1.131:40519
Nov 19 09:38 : client: [0] process command "commands"
Nov 19 09:38 : client: [0] command returned 0
Nov 19 09:38 : client: [1] opened from 192.168.1.131:40520
Nov 19 09:38 : client: [1] process command "commands"
Nov 19 09:38 : client: [1] command returned 0
Nov 19 09:38 : client: [0] process command "list "albumartist""
Nov 19 09:38 : client: [0] command returned 0
Nov 19 09:38 : client: [0] process command "list "artist""
Nov 19 09:38 : client: [0] command returned 0
Nov 19 09:38 : client: [0] process command "list "album" "group" "artist""
Nov 19 09:38 : client: [0] command returned 0
Nov 19 09:38 : client: [0] process command "list "al

Re: Radeon discrete graphics issues

[Timothy Legge]

So after re-reading man pages and a quick consultation of some Wikipedia
pages, kernel support for most Radeon cards upto those in the Northern
Islands family are supported. That ties in nicely with what you've outlined
as thats the family that came before they made the change to the GCN
Microarchitecture and Instruction set.

Hopefully it's something that will be supported in the not too distant
future.Until then, it's back in my box.

Thanks all.

On 19 November 2017 at 01:34, Jonathan Gray  wrote:

> The userland driver that page describes won't work without kernel support.
>
> For GCN parts like OLAND it is worse as they require Mesa to be built
> against LLVM libraries for 2D acceleration.  And LLVM libraries/llvm-config
> etc are not built/shipped in base.
>
> On Sun, Nov 19, 2017 at 01:16:19AM +, Timothy Legge wrote:
> > I copy/pasted "OLAND Radeon HD 8000 series" from the radeon(4)
> >  man page under the section header
> > "Supported Hardware". Maybe I'm missing something.
> >
> > On 19 November 2017 at 01:08, Jonathan Gray  wrote:
> >
> > > On Sat, Nov 18, 2017 at 07:43:03PM +, Timothy Legge wrote:
> > > > @Maurice, Don't worry about teaching me to suck eggs, I'd rather
> cover
> > > all
> > > > the bases :)
> > > >
> > > > I've run "fw_update -a"  to ensure that the drivers are installed and
> > > where
> > > > they need to be. (Bit overkill I know, but I'd rather be sure at this
> > > > point.)
> > > > As for support from the Radeon driver as linked above, it falls
> under the
> > > > "OLAND Radeon HD 8000 series".
> > >
> > > The radeon code in the kernel is derived from Linux 3.8, support for
> > > the OLAND family wasn't added till 3.9.
> > >
> > > > It's almost as though the kernel forgets to add "radeondrm0 at vga1"
> and
> > > > "drm0 at radeondrm0" as seen on other dmesg from systems with Radeon
> > > cards.
> > > > I can't help shake the sense that the fix to this is going to be
> > > something
> > > > rather simple, and I'm just too stupid to figure it out! :)
> > > >
> > > > On 18 November 2017 at 19:14, Maurice McCarthy 
> > > wrote:
> > > >
> > > > > I assume the radeon firmware is in /etc/firmware. If not download
> > > > > http://firmware.openbsd.org/firmware/6.2/radeondrm-
> > > firmware-20150927.tgz
> > > > > and untar it in that directory. (Sorry if I'm teaching granny to
> suck
> > > > > eggs.)
> > > > >
> > > > >
> > > > >  > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > Virus-free.
> > > > > www.avast.com
> > > > >  > > > > source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >
> > >
>