The following reply was made to PR kernel/6396; it has been noted by GNATS.
From: Theo de Raadt
To: Johan Torin
Cc: gn...@openbsd.org
Subject: Re: kernel/6396: Insert run(4) device, sh /etc/netstart run0, wait 10
seconds, boom!
Date: Sun, 06 Jun 2010 21:46:14 -0600
*7 0 0
> ips driver found 2300 cart, but no scsibus and no sd.
> 2313 found ips and scsibus, but not sd.
>
>
> In google i found http://readlist.com/lists/openbsd.org/misc/5/29424.html
> hoe must seen my cards:
> <= good stuff=>
> isp0 at pci3 dev 3 function 0 "QLogic ISP2300" rev 0x01: irq 11
>
You realize you are asking for twice as much work to be done?
> > binary patches are *only* available for the most recent release,
> > though - it being 6.2.
>
> Hi,
>
> would it be possible to provide binary patches during complete
> supported lifecycle of a release in the future?
>
> Because
> > You realize you are asking for twice as much work to be done?
>
> Can I help with additional work?
No, because signed syspatches are created in tightly controlled
environments.
> It becomes nonresponsive I have to hold the power button to restart. I
> can't imagine what else I can do to help you all out. It may be a symptom
> of a bigger problem, so I thought I'd try to report it for you.
Please stop mailing until you have something constructive to report.
I hope noone helps you.
> It doesn't really matter. I just trying to help you out. Isn't it your
> desire to fix bugs in your own operating system?
You are not helping out.
You are doing the bare mininum and tapping on a keyboard.
> I could run some commands if you want. I told you everything I am aware
> that I can do. I am still at the ddb prompt. Would you like me to do
> something and send another picture?
no, we wouldn't want to burden you
You cannot file bug reports in this way for snapshots.
They are not releases.
The right people will not read your reports.
Find the right person who works on that specific piece of software
and talk to them.
Your process will not solve anything.
You haven't read the FAQ regarding snapshots at
Look in dmesg. This is probably pledge.
PLease test with new library also.
> Since Mar 17 snapshot all relayd TLS regression tests fail. The
> relayd child processes crash at startup in BIO_new_file().
>
> bluhm
>
> Core was generated by `relayd'.
> Program terminated with signal SIGABRT, Abo
I'm facing a very high interrupt rate on irq0/clock on a Dell Latitude
E7450 laptop.
interrupt total rate
irq0/clock 419735 389
100 per cpu. 4 cpus.
Looks a lot like this:
interrupt total
Philip Guenther wrote:
> On Sat, 7 Apr 2018, Sebastien Marie wrote:
> > While running testsuite on third-party program, I found some weird
> > behaviour on us side regarding socketpair(2) and getpeereid(3).
> >
> > I ported the unit test to C (it was Rust) to check more easily.
> >
> > It just
Evan Rowley wrote:
> Hello OpenBSD Devs,
>
> Hopefully this bug-related question will not be too off-topic. I was
> curious as to the reason for continued SPARC support and saw this
> interesting sentence on the sparc64 page
> (https://www.openbsd.org/sparc64.html).
>
> "The other architectures
For a while it was amazing watching someone completely misunderstand
the Zeitgeist of the circumstances this is open source, you get
all the pieces from people who largely care, but you also get all
the pieces so that you can DECIDE to care and FIX them when you find
problems and participate i
Mischa wrote:
> > 2. Change the default owner group to root:_vmd.
> >
> > It would be possible to define a hardcoded group, or use group _vmd,
> > but this doesn't feel right.
>
> Why would using _vmd not work?
> Wouldn't that be the same for other daemons?
> Or wouldn't these be used to assig
p...@centroid.eu wrote:
> Trying to enter an skey system with scp is impossible. Or maybe I'm
> just that stupid.
> >How-To-Repeat:
> scp user:skey@localhost:/tmp/somefile .
> >Fix:
> beta# echo 12 > /tmp/blah
>
> beta# scp
Stefan Sperling wrote:
> On Tue, Jul 03, 2018 at 12:54:36PM +0100, Stuart Henderson wrote:
> > On 2018/07/03 13:42, Stefan Sperling wrote:
> > > On Tue, Jul 03, 2018 at 01:34:09PM +0200, David Dahlberg wrote:
> > > > Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> > > > > Not a
>I have provided a test program that shows the hex locations of both
>methods to back this up. It's in the how to repeat section.
Well, your test program is wrong; addresslocation is of the wrong type
pointing at an object of different size. It does not match what the
kernel cod
Bryan Vyhmeister wrote:
> On Thu, Jul 19, 2018 at 02:33:39PM -0400, Bryan Steele wrote:
> > This is due to vendors dropping support for ACPI S3 (Suspend-to-RAM), and
> > instead now favouring subsets of S0 called "S0ix", which are unsupported.
> >
> > Lots of recent discussion about this happeni
Martin Pieuchot wrote:
> On 20/07/18(Fri) 03:12, Mike Larkin wrote:
> > On Wed, Jul 18, 2018 at 11:34:41PM +, Romain wrote:
> > > > I'm wondering if this is due to the fact that we detach usb(4) devices
> > > > on
> > > > suspend. Looks like this may be trying to process a timeout that
> >
> I guess it occurs because ntpd does not poll constraints servers as often
> as ntp peers.
I've sees this proposed before.
Why would it need to poll again?
The constraints servers gave it a (latency shifted, but less than 1s
since internet doesn't reach mars yet), which we can compare against
t
It looks like my (large) unveil diff for calendar isn't working quite
right. I really would like if someone who uses calendar a lot would
take the diff over...
We don't agree.
We consider it a bug in KVM.
Doesn't KVM suggest they are emulating a real machine? AMD has
documented that MSR. So KVM should emulate the MSR. In some
way, even perhaps act like it is a NOP.
Or they shouldn't claim to be that CPU.
Feel free to report to those other upstreams
Elias M. Mariani wrote:
> You are right, is KVM's bug.
> But this was fixed on -snapshots right?
No.
> If so, OpenBSD 6.4 would work well, bypassing KVM's bug.
No.
Stuart Henderson wrote:
> On 2018/08/11 19:32, Sebastien Marie wrote:
> > I am also
> > unsure if loadfirmware() steal the slaacd context due to the use of
> > `curproc'.
>
> since it was using ifconfig context (as seen with unveil) that s
Stuart Henderson wrote:
> On 2018/08/11 15:57, Theo de Raadt wrote:
> > Stuart Henderson wrote:
> >
> > > On 2018/08/11 19:32, Sebastien Marie wrote:
> > > > I am also
> > > > unsure if lo
A number of workarounds for that specific ethernet chip were
commited after 6.3. It has some severe errata...
Landry Breuil wrote:
> On Sat, Jul 04, 2020 at 05:58:07PM +1000, Jonathan Gray wrote:
> > On Fri, Jul 03, 2020 at 11:14:02PM -0400, Joe Gidi wrote:
> > > Hello,
> > >
> >
> > firefox seems to be doing a dlopen after it has unveil'd and can't
> > open libLLVM. unveil removes visibility of parts
Pretty obvious if you dig into the guts of the program.
fetch.c:oldintr = signal(SIGINT, aborthttp);
fetch.c:oldintr = signal(SIGINT, aborthttp);
fetch.c:(void)signal(SIGINT, (sig_t)intr);
means:
static void
aborthttp(int signo)
{
const char errmsg[] = "\nfetch ab
The problem with setjmp is the frame indicating where you were is destroyed.
So you can't tell where you were, but the crash indicates you were in malloc.
ftp(1755) in free(): recursive call
Stuart Henderson wrote:
> user timecounters do not work everywhere, they require invariant TSC
> ("ITSC" shown in cpu flags), plus they require that the TSCs are in
> fairly close sync on the different cores, and that they don't drift
> too much.
>
> On your machine there is too much difference
Stuart Henderson wrote:
> On 2020/07/15 02:32, ken.hendrick...@l3harris.com wrote:
> >
> > Perhaps I am doing something wrong. Or maybe there is a bug.
> >
> > I have done quite a few installs in the last couple of weeks,
> > and on first boot, /etc/rc.firsttime doesn't work. It seems
> > tha
Soumendra Ganguly wrote:
> Hello, OpenBSD!
>I am using script(1) to complement a program that I am writing.
> However, the current OpenBSD version of script(1) is very old [ based
> on NetBSD script(1) version 1.3 ].
First off, it is not old. We don't automatically grab changes from
com
Soumendra Ganguly wrote:
> Theo,
> The replay feature does not make script(1) re-enter the
> commands. It simply replays them on the terminal as if it were a video
> [ like "cat typescript" but slower ]. It is particularly useful if
> someone wants to replay [ not re-run ] a curses session
Soumendra Ganguly wrote:
> based on the fact that tty operations should not be performed on stdin
> if it is not a tty [ maybe it is a regular file ]. This observation
> was made by bl...@openbsd.org. I claim that only
>
> if (tcgetattr(STDIN_FILENO, &tt) == 0 &&
>
Solene Rapenne wrote:
> On Mon, 17 Aug 2020 14:40:20 +
> blithering :
>
> > Hello,
>
> Hello,
>
> Could you provide addresses of git hosting services as alternatives
> to github that are as reliable as github?
I see no point discussing this with the internet rabble. At most,
github is a
nyone who just wants to
> casually read the source code I find that problematic.
>
> In all honesty, I don't have a solid technical reason for switching to
> another platform. CVS seems to work just fine.
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Monday
Out of memory.
#5 0x03dc9210f8a7 in mozalloc_handle_oom () from /usr/local/bin/firefox
Over this cycle, installboot.c was extended to do the 'bootblock
installation' process itself.
src/distrib/loongson/ramdisk/install.md lost this:
-
- # Use cat below to avoid holes created by cp(1)
- if mount -t ext2fs /dev/${_disk}i /mnt2 &&
- mkdir -p /mnt2/boot &&
-
Oh my aren't you the clever one!
Your closing sentence:
> This information may then be used to advance an attack.
By all means, please show how you do that.
Srikar V wrote:
> An attacker can use Local File Inclusion (LFI) to trick the web application
> into exposing or running files on the w
Todd C. Miller wrote:
> For some reason, cmplabel() in disklabel.c doesn't compare the
> bounds values when it checks for changes. I'm not sure what the
> reason for that is, it seems like we should write the new label
> even if the only change is in the bounds.
I guess it got missed. Let's se
Demi M. Obenour wrote:
> On 10/24/20 10:41 AM, Stefan Sperling wrote:
> > On Sat, Oct 24, 2020 at 04:11:00PM +0200, Filippo Valsorda wrote:
> >> Fair enough, but "there's no auto-assembly and it's inefficient and
> >> nothing stops you from messing with the intermediate discipline" is a
> >> diff
Filippo Valsorda wrote:
> Said another way, how was I supposed to find out this is unsupported?
The way you just found out.
> It's not like "a mirrored full-disk encrypted device" is an exotic
> configuration that would give me pause.
there's a song that goes "You can't always get what you wan
Filippo Valsorda wrote:
> 2020-10-24 19:01 GMT+02:00 Theo de Raadt :
>
> Filippo Valsorda wrote:
>
> > Said another way, how was I supposed to find out this is unsupported?
>
> The way you just found out.
>
> > It's not like "a mirror
Luke Small wrote:
> from man _exit:
>
> All open file descriptors in the calling process are closed. This
> may entail delays; for example, *waiting for output to drain*. A
> process in this state may not be killed, as it is already dying.
You think it is talking about stdio
Damjan Dimitrov wrote:
> Hi,
>
> A patch for mcx was committed 2 days ago which solved the "hca enable
> timeout" issue we had on 6.8 and HPE G10 hardware.
> (Commit:
> https://github.com/openbsd/src/commit/2e7f2cc2d7f8247f2ed5417f94311c602763e125)
> Many thanks for that and for working on the
Brian Kelk wrote:
> Hi. Some feedback after installing 6.8 on a G3 iMac by CD:
>
> 1. After the 'sets' step in the installer it says
>
> directory does not include SHA256.sig
>
> (but it lets me continue).
A few media don't have keys on them.
> 2. At the end of installation if
this will be the same bug recently reported against powerpc, for which
a diff is being passed around.
wict...@iki.fi wrote:
> Dear bugs,
>
> In 6.8-RELEASE I get strange results when I run the following script:
>
> #!/bin/sh
>
> set -x
>
> ifconfig wg0 create
> ifconfig wg0 wgkey "$(openssl
Miod Vallat wrote:
> It would probably be a better solution to introduce an Octeon-like BOOT
> kernel on loongson and use it as the bootloader on all loongson
> platforms, if only because of the dire bugs in their ext2fs
> implementation.
>
> Doing this would make the Gdium-specific boot shenani
I think this approach will lead to madness.
For one, it will make fstat randomly fail, very rarely. So if someone in
userland scripts on top of it, their scripts will extremely rarely fail
on them. That is horrific.
Looks like aggressive micro-locking was introduced without considering
the cons
Alexander Bluhm wrote:
> On Thu, Nov 26, 2020 at 04:51:23PM +0100, Marcus MERIGHI wrote:
> > Starting stack trace...
> > panic(81de557b) at panic+0x11d
> > kerntrap(8000229c1630) at kerntrap+0x114
> > alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
> > fill_file(80ca80
Well you didn't allocate a stack.
That mmap needs MAP_STACK
Or, you use the pthread APIs which allocate stacks, for instance
pthread_create().
In this case you are calling pthread_attr_setstack(), which has code
to re-create the stack allocation with MAP_STACK.
Why is that not working?
Sebas
Jonathan Gray wrote:
> > Index: sys/arch/i386/include/setjmp.h
> > ===
> > RCS file: /mount/openbsd/cvs/src/sys/arch/i386/include/setjmp.h,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 setjmp.h
> > --- sys/arch/i386/include/setj
Jason McIntyre wrote:
> On Sun, Dec 13, 2020 at 05:58:08PM +, Brian Kelk wrote:
> > Hi.
> >
> > The man page for passwd says that the length of a password must be
> > less than a specified value. Less than or equal to would make more
> > sense, surely?
> >
> > Brian Kelk
> >
>
> hi.
>
>
Brad Smith wrote:
> On 12/23/2020 10:35 PM, Alexey Sokolov wrote:
> >> Synopsis: getaddrinfo() is not thread-safe in 6.8
> >> Category: system
> >> Environment:
> > System : OpenBSD 6.8
> > Details : OpenBSD 6.8 (GENERIC.MP) #1: Tue Nov 3 09:06:04 MST 2020
> >
You've done a spectacular job deleting all the required information about
the machine.
Why would you do that?
Lucas wrote:
> Hello bugs@,
>
> as the subject says, I'm getting that message in dmesg and the OS seems
> quite broken. It started to happen after resuming from hibernate. The
> dmesg
So was that a fd leak?
(your error is EMFILE, not ENFILE. It is the process hitting fd limit)
Bob Beck wrote:
>
>
> On Tue, Jan 12, 2021 at 04:45:32PM +0100, Solene Rapenne wrote:
> > Hello,
> >
> > it seems www.openbsd.org is down since 14h46 UTC
> > If I remember correctly you are the rig
> What happened between 07:35:01 and 07:36:19?
Good point.
I think httpd crashed, or was killed by a script, and a new httpd was
started. But that new httpd was unable to get fd's at startup.
Bob, do you have a script like that?
Yet, it was EMFILE, not ENFILE.
Florian Obser wrote:
> > So that failure was on startup.. interesting.
>
> Not really :(
> It's that stupid thing where it creates O(n^2) amount of FDs to pass
> between the children to create a full mesh.
"Too many open files" is EMFILE.
It wasn't system fd pressure, or it would be ENFILE.
Otto Moerbeek wrote:
> On Wed, Jan 20, 2021 at 07:04:08AM +0100, Christian Jullien wrote:
>
> > Hi,
> >
> > I'm running OpenBSD 6.8 on arm :
> >
> > $ sysctl | grep hw
> > hw.machine=armv7
> > hw.model=ARM Cortex-A8 r3p2
> > hw.ncpu=1
> > hw.byteorder=1234
> > hw.pagesize=4096
> > hw.disknames
>
> C.
>
> -----Original Message-
> From: Theo de Raadt [mailto:dera...@openbsd.org]
> Sent: Wednesday, January 20, 2021 08:41
> To: Otto Moerbeek
> Cc: jull...@eligis.com; bugs@openbsd.org
> Subject: Re: munmap sometimes does coredump on arm after mmap success
>
Christian Jullien wrote:
> My allocator is much complex than that, it has start heuristics and then
> makes different mmap/munmap until it finds a location having the right
> (possibly reduced) size.
> That's why I was surprised to see munmap failed after successful mmap.
There is no possible st
> Even if the behavior is still strange for me, I accept how it behaves on
> OpenBSD.
mmap and munmap work the same on all systems.
You are just less likely to replace used memory, which is relied upon.
There are a bunch of problems being caused by some sort of kernel
memory exhaustion.
Whatever it is, I think it was introduced back around November
My point is this is unrecoverable. It seems to happen quite suddenly.
Jonathan Matthew wrote:
> On Mon, Feb 22, 2021 at 01:48:01PM +, Stuart
bernward@arcor.de wrote:
> >Synopsis:system upgrade: /usr/share/relink/kernel/GENERIC.MP was not
> >updated
> >Category:system
> >Environment:
> System : OpenBSD 6.6
> Details : OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT
> 2019
>
bernward@arcor.de wrote:
> On 2019-11-05 05:52, Theo de Raadt wrote:
> >
> > > The directory GENERIC.MP in /usr/share/relink/kernel/ was
> > > obviosly not updated (but directory GENERIC was updated!).
> >
> > I doubt it. Upon upgrade, they are both r
1MB is the current limit, for three reasons initially, but now two
remaining reason.
Looking at vmcmd_randomize, you'll see it allocates all the pages
up front. That is reason #1. They are not demand-allocated (and
then filled with random). I had some draft uvm code for years ago
but it is pret
> kern.version=OpenBSD 6.6-current (GENERIC.MP) #433: Thu Nov 7 10:41:08 MST
> 2019
That is too old and does not contain the solution.
Timely fix isn't it :-)
Theo Buehler wrote:
> On Thu, Nov 07, 2019 at 03:10:45PM -0800, Philip Guenther wrote:
> > On Thu, 7 Nov 2019, Theo Buehler wrote:
> > > On Thu, Nov 07, 2019 at 03:32:48PM -0700, Theo de Raadt wrote:
> > > > > kern.version=OpenBSD
Vladislav Basargin wrote:
> Hello.
>
> I'm encountered a warning due to OpenBSD installation to my VPS
> (tk1tez.tk currently) with the iso file
> (https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.6/amd64/install66.iso)
> about SHA256 signatures.
>
> DIrectory doesn't contain SHA256.sig
>
> I
Yeah, oops.
Florian Obser wrote:
> I updated my X1 gen2 to
> Build date: 1573279451 - Sat Nov 9 06:04:11 UTC 2019
> and I can no longer type my FDE password.
> Booting a miniroot.fs from usb results in the machine hanging at
> boot>
>
> This is a known good snapshot:
> Build
Antoine Jacoutot wrote:
> On Sat, Nov 09, 2019 at 02:13:01PM +0100, Florian Obser wrote:
> > I updated my X1 gen2 to
> > Build date: 1573279451 - Sat Nov 9 06:04:11 UTC 2019
> > and I can no longer type my FDE password.
> > Booting a miniroot.fs from usb results in the machine hanging at
> >
>On Sun, 17 Nov 2019 20:38:59 +0100, Alexander Bluhm wrote:
>
>> I think the best way to handle it, is to make the kernel strict and
>> fix userland. If the kernel would allow the sloppiest userland
>> program to succeed, creating security would be hard.
>
>Sorry, I don't agree. We cannot expect
>>On Sun, 17 Nov 2019 20:38:59 +0100, Alexander Bluhm wrote:
>>
>>> I think the best way to handle it, is to make the kernel strict and
>>> fix userland. If the kernel would allow the sloppiest userland
>>> program to succeed, creating security would be hard.
>>
>>Sorry, I don't agree. We cannot
>I think the best way to handle it, is to make the kernel strict and
>fix userland. If the kernel would allow the sloppiest userland
>program to succeed, creating security would be hard.
>
>So patching dhcpcd is the right approach. Thanks for finding.
I disagree.
I think the new kernel test is
Of course it is zero filled. What else would it be? There are no
plausible alternatives.
I think it detracts from the rest of the message to say something
so obvious.
>In the man page of mmap(2), the description of the flag MAP_ANON does
>not indicate the state of the newly allocated memory.
>
emilien.lamb...@zbim.org wrote:
> Since the man pages are "the authoritative source of information for
> OpenBSD", I am currently forced to assume that the newly allocated
> memory is in an undefined state (because that state is not defined in
> the documentation). I can't rely on an undocumented
that seems sensible :)
Alexander Bluhm wrote:
> On Mon, Nov 18, 2019 at 08:42:30AM +0100, Claudio Jeker wrote:
> > On Sun, Nov 17, 2019 at 02:03:21PM -0700, Todd C. Miller wrote:
> > > On Sun, 17 Nov 2019 20:38:59 +0100, Alexander Bluhm wrote:
> > >
> > > > I think the best way to handle it, is
Lars Schotte wrote:
> Yes, I found that in the meantime too.
>
> However, I saw a longer diff.
> Something like this one:
> https://www.mail-archive.com/misc@openbsd.org/msg169682.html
>
> Anyway. That would be nice if fix is already comitted into -current.
>
> Upgrading to unstable is not an
Lars Schotte wrote:
> OK, I will try that out some time this week.
>
> And, yes, with the syspatches for mips64, that's what I wanted to hint.
Isn't it rude to hint that other people should do work for you?
Lars Schotte wrote:
> "unstable" is already a move forward from "unusable".
> I mean a DSL router without PPPoE does not do much, right?
>
> Yes, I was doing that compiling on EdgeRouter Lite once.
> That was a pain.
> And I d rather change that to a x86_64 atom instead of
> compiling ANYTHING o
Lars Schotte wrote:
> NO, that's not what I wanted to say.
>
> I was pointing out that it would be absolutely great to have this
> working.
No, you whined like an asshole and then called our ongoing work
towards the next release with dismissive names. You are an asshole
and should go run somet
Marko Cupać wrote:
> On Sun, 08 Dec 2019 12:01:37 +0100
> Antoine Jacoutot wrote:
>
> > Actually having /var mounted over MFS is absolutely not supported
> > (because this is where we store rollback tarballs and where syspatch
> > checks to see whether a particular patch has been installed).
>
Marko,
The software comes without warranty, and you don't get to yell at
developers about what they should do.
Maybe Linux does what you want?
Marko Cupać wrote:
> On Thu, 12 Dec 2019 17:07:59 +0100
> Claudio Jeker wrote:
>
> > You changed the FS type from the default used by the installer
Marko Cupać wrote:
> And I also think that "component X of
> OpenBSD won't do Y" should not be worded as "not supported by OpenBSD".
Look, you are wrong. People who can commit get to make that decision
and your opinion doesn't matter.
We are not going to write code for your crazy tweak. Becau
+ user = strsep(&tmp, ":");
Can't that also return NULL?
Sebastien Marie wrote:
> On Sat, Dec 07, 2019 at 11:47:58AM +0100, Sebastien Marie wrote:
> >
> > For now, I recompiled slaacd with debug symbols, and will keep it running
> > like
> > that in order to catch it the next time. But such switchs aren't very
> > frequent...
>
> A new one, with sym
Theo de Raadt wrote:
> Sebastien Marie wrote:
>
> > On Sat, Dec 07, 2019 at 11:47:58AM +0100, Sebastien Marie wrote:
> > >
> > > For now, I recompiled slaacd with debug symbols, and will keep it running
> > > like
> > > that in order to catc
Thomas Dickey wrote:
> On Tue, Jan 07, 2020 at 09:00:04PM +0100, Benjamin Baier wrote:
> > >Synopsis: xterm pledge dns violation
> > >Category: X11 / libc? / ports?
> > >Environment:
> > System : OpenBSD 6.6
> > Details : OpenBSD 6.6-current (GENERIC.MP) #0: Mon Jan 6 20:17:42
Jeremie Courreges-Anglas wrote:
> I'm not ok with that approach, I think IP_ADDRESS should just go.
> Upstream doesn't seem to care much about it:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=7611
I think it is some misguided historical code which should not be in
this library. It is sim
There have been a few reports, but nothing with a clue for us yet.
Can you modify your /etc/rc to run prepend something like
"ktrace -di -o /somewherewithspace/ktrace.out" to the relink operation,
and when it fails, kdump and look for clues?
>On Thu, 30 Jan 2020 21:14:20 +1100
>Brett Mahar wrote
Well, I have been given this particilular MC7700 which works as umsm,
but it does *NOT* match as umb, probably because it's firmware is too
old? Or it is in the wrong mode, I can't tell.
The alternative is that the device cannot attach at all.
How does this get resolved? I can dig it up and sho
I've told Lee to test something for me.
I think the priority from match functions are being confused via
these (stupid) UMATCH_* variables, which are some weird disguise for
what is supposed to be a priority code.
In his upgraded case, ubm should win. it returns
UMATCH_IFACECLASS_IFACESUBCLASS_I
Gerhard Roth wrote:
> thank you very much for your generous offer. But I don't think this is
> needed. I think the umsm(4) vs. umb(4) attach problem can be attacked
> without having this specific device as it happens with other Sierra
> Wireless devices, too.
Yes, it looks like the testing reque
leeb wrote:
> OK, just rebuilt my kernel:
>
> x230$ grep MC7700 umsm.c
> {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0},
> x230$ diff if_umb.c if_umb.c.~1.31.~
>
> 276,277c276
> < /* return UMATCH_IFACECLASS_IFACESUBCLAS
Frédéric Dhieux wrote:
> Hi OpenBSD team,
>
> I would like to report a problem I have, we have in production many OpenBSD
> where we remove X*, game* and comp* at the install.
>
> Everything is fine except sysupgrade adds every sets again when I try to
> upgrade my OpenBSD version. Is it poss
Denis wrote:
> I installed MC77xx about three years ago into OpenBSD driven machine. It
> actively uses everyday with msm mode driver. The question was how to
> detect UMB and MSM devices and attach suitable driver simultaneously
> (msm + umb) for single device according to USB descriptors for ea
Mark Kettenis wrote:
> Well, my EM7345 shows up as:
>
> umb0 at uhub0 port 4 configuration 1 interface 0 "Sierra Wireless Inc. Sierra
> Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2
> umodem0 at uhub0 port 4 configuration 1 interface 2 "Sierra Wireless Inc.
> Sierra Wireless EM7345 4G LTE" rev
="ADBENABLE",1
> or AT!CUSTOM="ADBENABLE",0 to disable ADB port
> AT!RESET
>
> *** to check ADB port state after changes it is recommended to reconnect
> modem's power
>
>
> Denis
>
>
> On 2/13/2020 8:04 PM, Theo de Raadt wrote:
> >
Denis wrote:
> It was marked as "not necessary" to implement both driver for one Sierra
> device. So work was stopped before begin right on descriptors...
No what is happening is you keep begging for functionality but not
writing it. Do the work or adjust your expectations.
1 - 100 of 548 matches
Mail list logo
