27;d better let somebody know that I'm getting an ssl error on firefox
> trying to connect to firmware.openbsd.org/firmware over https.
https is not supported for that.
--
Please keep replies on the mailing list.
Kia Ora, it's my first time using these mailing lists,
my apologies if I'm not following proper "netiquette", but I thought
I'd better let somebody know that I'm getting an ssl error on firefox
trying to connect to firmware.openbsd.org/firmware over https.
as ment
> installboot: mkdir('/tmp/installboot./efi/BOOT')
>
> failed: Not a directory
>
> Failed to install bootblocks
> You will not be able to boot OpenBSD rom sd0
>
> I was able to recover with 'fdisk -e' and 'reinit'. This allowed the
>
otblocks
You will not be able to boot OpenBSD rom sd0
I was able to recover with 'fdisk -e' and 'reinit'. This allowed the
installer to complete, but the machine still did not boot, as it
appears all the UEFI boot records in the firmware were wiped.
Recovery was by boot
to go to download firmware files for my intel
> > wireless card?
>
> Yes.
> Run `man fw_update` in your terminal.
>
> All free aka open-source firmware is included in the OS as far as I know (not
> sure if it is in a separate fileset or what), and the non-free aka malware aka
Vào Th 5, 12 thg 9, 2024 vào lúc 02:15 Anon Loli
đã viết:
>
> On Tue, Sep 10, 2024 at 11:44:41PM -0400, openbsd_fr...@mail2tor.com wrote:
> > Is fw_update the way to go to download firmware files for my intel
> > wireless card?
>
> Yes.
> Run `man fw_update` in your
On Wed, Sep 11, 2024 at 05:12:49PM +, Anon Loli wrote:
> On Tue, Sep 10, 2024 at 11:44:41PM -0400, openbsd_fr...@mail2tor.com wrote:
> > Is fw_update the way to go to download firmware files for my intel
> > wireless card?
>
> Yes.
> Run `man fw_update` in your ter
On Tue, Sep 10, 2024 at 11:44:41PM -0400, openbsd_fr...@mail2tor.com wrote:
> Is fw_update the way to go to download firmware files for my intel
> wireless card?
Yes.
Run `man fw_update` in your terminal.
All free aka open-source firmware is included in the OS as far as I know (not
sure if
Yes.
Is fw_update the way to go to download firmware files for my intel
wireless card?
On Sun, 18 Feb 2024 10:57:27 +0100,
Stuart Henderson wrote:
>
> It's not too bad as long as the person building firmware tgz gets a
> heads-up before the version number is updated.
>
Specially that right now it still can be run as:
env VERSION=74 fw_update -p http://fir
napshot directory.
>> >
>>
>> And using snapshot directory fails because wrong signature:
>>
>> ~ $ doas fw_update -p http://firmware.openbsd.org/firmware/snapshots
>> fw_update: failed.
>> signify: verification failed: checked against wrong key
>&
because wrong signature:
>
> ~ $ doas fw_update -p http://firmware.openbsd.org/firmware/snapshots
> fw_update: failed.
> signify: verification failed: checked against wrong key
> Signature check of SHA256.sig failed
> ~ $
The heuristic in fw_update is weak. Every
mware.openbsd.org/firmware/snapshots
fw_update: failed.
signify: verification failed: checked against wrong key
Signature check of SHA256.sig failed
~ $
--
wbr, Kirill
Today "sysupgrade -s" failed to fetch updated firmware:
=
Verifying sets.
Fetching updated firmware.
fw_update: failed.
Cannot fetch http://firmware.openbsd.org/firmware/7.5//SHA256.sig (404
Not Found)
Upgrading.
=
Seems it's looking for
Seems to be solved.
http://firmware.openbsd.org/firmware/7.2/ now has content and:
2022T160436 root@mpc:~# fw_update -vvv
Detect firmware ... found.
Trying 145.238.169.11...
Requesting http://firmware.openbsd.org/firmware/7.2/SHA256.sig
100
On a newly installed Mini PC (NiPoGi AM02) I noticed the following messages in
dmesg:
iwm0: could not read firmware iwm-7265-17 (error 2)
iwm0: failed to load init firmware
and:
drm:pid0:amdgpu_device_parse_gpu_info_fw *ERROR* Failed to load gpu_info
firmware "amdgpu/raven2_gpu_inf
On Sat, Sep 17, 2022 at 09:17:03PM +0200, Quentin Schibler wrote:
> I have a laptop using an AX210 network card (no ethernet),
> which is supported by -current, but not by 7.1.
> I installed 7.1 without configuring network,
> rebooted, and dumped the iwx firmware
> 20220708 onto a
I have a laptop using an AX210 network card (no ethernet),
which is supported by -current, but not by 7.1.
I installed 7.1 without configuring network,
rebooted, and dumped the iwx firmware
20220708 onto a USB key.
I tried to fw_update -p . but it did not detected
iwx as added iwx.
I tried
On Wed, Jun 15, 2022 at 03:38:15AM +0200, Christian Schulte wrote:
>
>
> On 14.06.22 11:36, Stefan Sperling wrote:
> > I don't know what SYSASSERT 0x0005 is supposed to tell us. All
> > I can do is make guesses based on what changed between 7.0 and 7.1.
> >
> > In addition to the previous ch
debug messages. Regarding that sysassert,
I can only throw guesses at it. Maybe the firmware is checking some pre
condition, it relies on the driver to have checked, and just bails out?
Without any documentation, we'll never know. Router is a Fritz!Box 7362
SL and there are four Fritz WLAN Re
em to be succeeding.
These are using Tx queue 4 and this queue has no outsanding frames queued.
This implies that the firmware managed to ack all of our commands before
it crashed. So processing of the commands seems to be working.
I don't know what SYSASSERT 0x0005 is supposed to tell us. Al
On Mon, Jun 13, 2022 at 02:45:23AM +0200, Christian Schulte wrote:
>
>
> On 12.06.22 13:22, Stefan Sperling wrote:
> > On Sun, Jun 12, 2022 at 01:16:00PM +0200, Stefan Sperling wrote:
> > > On Sun, Jun 12, 2022 at 10:28:33AM +0200, Christian Schulte wrote:
> > > > Please see attached dmesg and pc
be related to those.
No issues with 7.0.
In any case we will need to figure out which command is failing for you.
The patch below adds additional debug output while 'ifconfig iwn0 debug'
is enabled and should display the command code sent to firmware. Hopefully
this can tell us whi
ut while 'ifconfig iwn0 debug'
is enabled and should display the command code sent to firmware. Hopefully
this can tell us which command firmware is complaining about.
Can you reproduce the failure with it again and send new debug output?
diff 83a9dfe1b14
On Sun, Jun 12, 2022 at 10:28:33AM +0200, Christian Schulte wrote:
> Please see attached dmesg and pcidump. There has been a similar issue with
> the if_iwm.c driver. Maybe this one is related.
These are seperate drivers so it is unlikely that these issues would
be related.
How many different acc
CI root hub" rev 1.00/1.00
addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
isa0 at
Please CC me. I am not subscribed to the list.
Hello,
after upgrading from 7.0 to 7.1, the iwn0 interface cannot be used
anymore, stating iwn0: fatal firmware error. I then checked out 7.1
stable, build the GENERIC.MP kernel, the system and xenocara. Issue
remains. Here's what dmesg con
Hey, Im having a bit problem with my Ryzen 9 4900H. When I install the
amdgpu firmware, I only get a black screen after it loads the
firmware. Im running -current. Im wondering if anyone else has this
problem. This is the error I get. I will attach my dmesg also.
drm:pid0:psp_get_runtime_db_entry
On Mon, Feb 21, 2022 at 04:53:50AM +, Claus Assmann wrote:
> On Mon, Feb 21, 2022, Jonathan Gray wrote:
>
> > No, it is not firmware. But I'd need to see a dmesg with inteldrm
> > enabled to comment further. In -current there is a different version of
>
On Mon, Feb 21, 2022, Jonathan Gray wrote:
> No, it is not firmware. But I'd need to see a dmesg with inteldrm
> enabled to comment further. In -current there is a different version of
That should be this one:
OpenBSD 7.0 (GENERIC) #224: Thu Sep 30 14:13:34 MDT 2021
de
hip for context closure in firefox<11842>
> Feb 19 11:06:10 vxrs /bsd: drm:pid1527:intel_gt_reset *NOTICE* [drm]
> Resetting chip for context closure in firefox<1527>
>
> According to some posting the firmware has to be updated, but AFAICT
> that requires to update th
id1527:intel_gt_reset *NOTICE* [drm] Resetting
chip for context closure in firefox<1527>
According to some posting the firmware has to be updated, but AFAICT
that requires to update the OS to a snapshot (i.e., I cannot install
the newer firmware on 7.0 and expect it to work?), hence it's not a
gs&m=163459084214897&w=2
Stefan,
Thanks,
mv /etc/firmware/iwm-7265D-29 /etc/firmware/iwm-7265D-29.orig
cp /etc/firmware/iwm-7265-17 /etc/firmware/iwm-7265D-29
and a reboot has improved things considerably!
The odd DNS timeout still gets logged but for all I know it always did
that running Open
On Tue, Dec 14, 2021 at 12:49:14PM +, Dave Turner wrote:
> I have searched the web and tried various things but so far nothing
> fixes it.
This should help: https://marc.info/?l=openbsd-bugs&m=163459084214897&w=2
sd: iwm0: fatal firmware error
Dec 5 11:36:37 ux305f /bsd: iwm0: could not remove MAC context (error
35)
I have tried various things to try and make it work properly.
Killing ntpd didn't help.
Editing resolv.conf to add the 208.67.222.222 Open DNS server didn't
help because resolvd adds na
On 17/11/2021 08:29, Luca Ferrari wrote:
On Tue, Nov 16, 2021 at 3:03 PM Noth wrote:
Run the installer as usual, then once that has finished:
umount /mnt2 (this is where the install sets are)
remove installer usb drive and insert usb drive with the firmware
mount /dev/sd1a (or sd1i if
On Tue, Nov 16, 2021 at 3:03 PM Noth wrote:
>
> Run the installer as usual, then once that has finished:
>
> umount /mnt2 (this is where the install sets are)
>
> remove installer usb drive and insert usb drive with the firmware
>
> mount /dev/sd1a (or sd1i if using vfat
with full disk install.
Then, you can fix the firmware using the fw_update command, not the pkg_add
if I recall correctly.
In the meantime, maybe someone more knowledgeable can give you some useful
advice with minirootXX.img and firmware, if that is possible to install.
Run the installer as usual, then once that has finished:
umount /mnt2 (this is where the install sets are)
remove installer usb drive and insert usb drive with the firmware
mount /dev/sd1a (or sd1i if using vfat) /mnt2
cp /mnt2/iwn-firmware-version.tgz /mnt/root
chroot /mnt
pkg_add /root
d.org
> Betreff: Re: adding firmware during installation
>
> On Tue, Nov 16, 2021 at 2:30 PM Kapfhammer, Stefan
> wrote:
> > yes, you need to do stuff manually, because you are going an unusual way.
>
> the fact is, as far as I understand, that before installing etc
Hi,
yes, you need to do stuff manually, because you are going an unusual way.
-Stefan
> -Ursprüngliche Nachricht-
> Von: Luca Ferrari
> Gesendet: Dienstag, 16. November 2021 13:18
> An: Kapfhammer, Stefan
> Cc: misc@openbsd.org
> Betreff: Re: adding firmware d
On Tue, Nov 16, 2021 at 2:30 PM Kapfhammer, Stefan wrote:
> yes, you need to do stuff manually, because you are going an unusual way.
the fact is, as far as I understand, that before installing etc.tgz
the system will not have /etc/firmware writable, and at that time I
can simply reboot
Hi,
extract the files of the firmware package before and place them
in [mountpoint-during-installation]/etc/firmware.
-Stefan
> -Ursprüngliche Nachricht-
> Von: owner-m...@openbsd.org Im Auftrag
> von Luca Ferrari
> Gesendet: Dienstag, 16. November 2021 12:34
> An: m
On Tue, Nov 16, 2021 at 12:44 PM Kapfhammer, Stefan wrote:
> extract the files of the firmware package before and place them
> in [mountpoint-during-installation]/etc/firmware.
Sorry, but this is not clear to me: what do you mean with mountpoint?
Because I'm installing from rd0a,
On Tue, Nov 16, 2021 at 12:49 PM Jan Stary wrote:
> But you already have the iwn firmware,
> so you must have some other connection ...
I don't have ethernet connection, or it would be easier!
I have downloaded the firmware from another computer, and placed into
a second USB stick t
If iwn is your _only_ connection,
you need to have the iwn firmware.
Can you install with ethernet plugged it?
That will download the firmware for you.
But you already have the iwn firmware,
so you must have some other connection ...
On Nov 16 12:34:16, fluca1...@gmail.com wrote:
> Hi
Hi all,
I'm installing OpenBSD 7.0 on a Lenovo Thinkpad T410, and I need the
firmware iwn-firmware-5.11p1.tgz for the wireless card.
Therefore, I opened a shell from the installer, mounted the USB stick
I placed the downloaded firmware on, and now I'm stuck: I cannot
install it because
nwid mynet wpakey mykey
> > dhcp
> >
> > iwm0: hw rev 0x210, fw ver 17.3216344376.0, address 18:5e:0f:ea:ff:c4
>
> This isn't the latest firmware yet, it's the firmware we've been using
> for a long time.
>
> > iwm0: Could not empty Tx queues (error 35)
>
ea:ff:c4
This isn't the latest firmware yet, it's the firmware we've been using
for a long time.
> iwm0: Could not empty Tx queues (error 35)
This is a driver-side issue which was recently introduced. The driver
treats this situation as an error while it is in fact a legit
un 0: naa.
sd2: 114473MB, 512 bytes/sector, 234441648 sectors, thin
ichiic0 at pci0 dev 31 function 3 "Intel 9 Series SMBus" rev 0x03: apic 2 int 18
iic0 at ichiic0
pchtemp0 at pci0 dev 31 function 6 "Intel 9 Series Thermal" rev 0x03
isa0 at pcib0
isadma0 at isa0
Marco Scholz [t...@disroot.org] wrote:
> Hello.
> My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal
> firmware error. I'm running 6.9 #29.
> System gets quite hot, systat shows 40-50% interrupt while idling.
> Networking works fine.
>
> Anybody else ha
On Mon, May 24, 2021 at 02:35:02PM +0200, Marco Scholz wrote:
> Hello.
> My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal
> firmware error. I'm running 6.9 #29.
> System gets quite hot, systat shows 40-50% interrupt while idling.
> Networking works fine.
>
Hello.
My laptop (Lenovo Thinkpad T495s AMD Ryzen) reports an iwm0 fatal
firmware error. I'm running 6.9 #29.
System gets quite hot, systat shows 40-50% interrupt while idling.
Networking works fine.
Anybody else has this issue?
Regards, Marco.
OpenBSD 6.9-current (GENERIC.MP) #29: Fri M
On Wed, Jan 13, 2021 at 04:10:46AM +0200, Mihai Popescu wrote:
> I took the chance and installed from a recent snapshot - 12.01.2021. I got
> a kernel panic at first boot after install, related to missing firmware for
> radeondrm.
> I disabled the radeondrm then the boot process wa
I took the chance and installed from a recent snapshot - 12.01.2021. I got
a kernel panic at first boot after install, related to missing firmware for
radeondrm.
I disabled the radeondrm then the boot process was fine and I installed
radeondrm firmware by hand. At the next boot everything was fine
On 2020-11-17, Mihai Popescu wrote:
> Recent snapshot install for amd64, first run reports the missing package
> from firmware.
Should be there now.
Recent snapshot install for amd64, first run reports the missing package
from firmware.
On 24 Sep 12:24, Jan Stary wrote:
> On Sep 24 11:36:24, h...@stare.cz wrote:
> > This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> > iwm stopped working, saying
> >
> > iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
> > iwm0:
4.0.1, address e4:a4:71:40:21:08
> > > iwm0: fatal firmware error
> > > iwm0: could not remove MAC context (error 35)
> > > iwm0: fatal firmware error
> > > iwm0: could not remove MAC context (error 35)
> > > iwm0: fatal firmware error
> > >
On 2020-09-24, Jan Stary wrote:
> This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> iwm stopped working, saying
>
> iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
> iwm0: fatal firmware error
> iwm0: could not remove MAC contex
On Sep 24 11:36:24, h...@stare.cz wrote:
> This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
> iwm stopped working, saying
>
> iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
> iwm0: fatal firmware error
> iwm0: could not remove MAC
This is 6.8-beta/amd64 on a Dell Latitude E5570 (dmesg below).
iwm stopped working, saying
iwm0: hw rev 0x200, fw ver 34.0.1, address e4:a4:71:40:21:08
iwm0: fatal firmware error
iwm0: could not remove MAC context (error 35)
iwm0: fatal firmware error
iwm0
perly, a lot of CPU security fixes are
> distributed as firmware microcode updates that have to be loaded by the
> OS. So... being inappropriately paranoid about firmware could compromise
> your security.
Especially if new backdoors (e.g. for rooting CPUs) are added in
Aaron Mason wrote:
> On Fri, May 15, 2020 at 3:39 AM Nick Holland
> wrote:
> >
> > On 2020-05-14 11:08, i...@aulix.com wrote:
> >
> > I actually had Adaptec give me a firmware update with a time bomb in
> > it, and didn't bother to tell me that after
On Fri, May 15, 2020 at 3:39 AM Nick Holland
wrote:
>
> On 2020-05-14 11:08, i...@aulix.com wrote:
>
> I actually had Adaptec give me a firmware update with a time bomb in
> it, and didn't bother to tell me that after X days, it would brick my
> adapter and prevent me from
On Thu, May 14, 2020 at 04:25:11AM +, Mogens Jensen wrote:
> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?
Others pointed out that firmwares are signed.
Fo
o do with OpenBSD. That can be true for any kind of
> code update, whether it exists in RAM on a device that's loaded by the
> OS at boot time, EEPROM that can be reprogrammed by software, or a
> chip that has to be physically swapped out.
>
> I actually had Adaptec give me a fir
update, whether it exists in RAM on a device that's loaded by the
OS at boot time, EEPROM that can be reprogrammed by software, or a
chip that has to be physically swapped out.
I actually had Adaptec give me a firmware update with a time bomb in
it, and didn't bother to tell me that after
i...@aulix.com wrote:
> > If that binary code was on a ROM, would it be less malicious?
>
> Cannot more recent and up to date binary code be more malicious than old one
> in the ROM?
Our firmwares do not replace code on ROM, since the hardware in question
HAS NO ROM.
> If that binary code was on a ROM, would it be less malicious?
Cannot more recent and up to date binary code be more malicious than old one in
the ROM?
Just because backdoor development is progressing as time goes and old backdoors
may be less dangerous compared to modern ones?
> If the binar
Janne Johansson wrote:
> Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen <
> mogens-jen...@protonmail.com>:
>
> > Normally I would just assume that fetched files are verified, but maybe
> > in the case with fw_update, the rationale is that firmware files are
> &
On 2020-05-14, Mogens Jensen wrote:
> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?
>
> There is a SHA256.sig in the remote firmware directory, but no
&g
I was just trying out the fw_update program on OpenBSD 6.5, deleting/
installing all the firmware and was wondering if fw_update will verify
the files before installing?
There is a SHA256.sig in the remote firmware directory, but no
indication from fw_update, even with verbose output, if this is
Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen <
mogens-jen...@protonmail.com>:
> Normally I would just assume that fetched files are verified, but maybe
> in the case with fw_update, the rationale is that firmware files are
> binary blobs so we can't know if they
The firmwares are packages, and are signed with the
/etc/signify/openbsd-XX-fs.pub key.
There is no risk.
Mogens Jensen wrote:
> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the fil
> Thanks for the report. Fixed in radeon_kms.c rev 1.60.
Installed, tested and it works.
Thank you.
On Sat, Apr 20, 2019 at 12:58:06AM +0300, Mihai Popescu wrote:
> Here is the error message part:
>
> initializing kernel modesetting (Rs880 0x1002:0x9715 0x17AA:0x3082 0x00).
> r600_cp: Failed to load firmware "radeon/RS780_pfp.bin"
> [drm] *ERROR* Failed to
Here is the error message part:
initializing kernel modesetting (Rs880 0x1002:0x9715 0x17AA:0x3082 0x00).
r600_cp: Failed to load firmware "radeon/RS780_pfp.bin"
[drm] *ERROR* Failed to load firmware!
drm:pid0: radeondrm_attachhook *ERROR* Fatal error during GPU init
uvm_fault(0xff
Hello,
I have installed the recent current snapshot for amd64. After
finishing and rebooting I got some kernel uvm fault after some message
about radeondrm firmware not installed. The keyboard was not usable.
I had to reboot and disable radeondrm, then run fw_update -a by hand.
Things were back
Many thanks to all for your explanations, as always.
Regards,
C. L. Martinez
From: owner-m...@openbsd.org on behalf of Kevin
Chadwick
Sent: 13 September 2018 17:39
To: misc@openbsd.org
Subject: Re: OT: Firmware encryption hacked?
On Thu, 13 Sep 2018 10
On Thu, 13 Sep 2018 10:23:11 -0400
> > Uhmm … Reality?
> > https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1
> >
>
> Somewhat better writup from the source:
>
> https://blog.f-secure.com/cold-boot-attacks/
>
> The vulnerabi
Carlos Lopez writes:
> Uhmm … Reality?
> https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1
Somewhat better writup from the source:
https://blog.f-secure.com/cold-boot-attacks/
The vulnerability seems to be when a computer is r
Uhmm … Reality?
https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1
Can we consider a risk to encrypt at OS level also?
errors automatically? It should be able
> to.
>
> As to why the firmware reports such errors: We have no idea. It's a black
> box.
>
As far as I can tell, it recovers. Lately, it's been doing it at odd hours
when I'm
not actually using it, but I've never come ba
Apr 4 04:30:01 luggy /bsd: iwi0: fatal firmware error
> Apr 4 05:17:37 luggy /bsd: iwi0: fatal firmware error
> Apr 4 05:17:39 luggy /bsd: iwi0: unknown authentication state 1
> Apr 4 05:17:40 luggy /bsd: iwi0: reused group key update received from
> 60:38:e0:89:9b:dc
> Apr 4 06
I have a Motorola ML900 which seems to be running OpenBSD with X and
WindowMaker just fine. Every few hours it gets a group of errors within the
span of a few seconds (about 1 second between them in /var/log/messages)
Apr 4 04:30:01 luggy /bsd: iwi0: fatal firmware error
Apr 4 05:17:37 luggy
ote:
> On Fri, Mar 23, 2018 at 05:43:50PM -0500, Alex Elizalde wrote:
> > Recently installed OpenBSD 6.2 amd64 and ran fw_update and syspatch.
> > Attempting to use the wireless card fails with the following messages:
> > iwm0: hw rev 0x220, fw ver 22.361476.0, address 10:f0:05:8f
On Fri, Mar 23, 2018 at 05:43:50PM -0500, Alex Elizalde wrote:
> Recently installed OpenBSD 6.2 amd64 and ran fw_update and syspatch.
> Attempting to use the wireless card fails with the following messages:
> iwm0: hw rev 0x220, fw ver 22.361476.0, address 10:f0:05:8f:42:8d
> iwm0: fa
Recently installed OpenBSD 6.2 amd64 and ran fw_update and syspatch.
Attempting to use the wireless card fails with the following messages:
iwm0: hw rev 0x220, fw ver 22.361476.0, address 10:f0:05:8f:42:8d
iwm0: fatal firmware error
iwm0: could not load firmware
iwm0: could not load firmware
iwm0
Dear Stefan and Z Ero,
Thank you.
I do not live in the US and it is very hard to get old parts, because
most of the sellers do to ship to where I live.
I think I can live with the unstable wireless adapter for now. I
probably should have spent less time on-line anyway. If I am too
bothered with
On Sat, Mar 03, 2018 at 05:49:33AM -0500, Z Ero wrote:
> I believe these era Thinkpads will not accept a non-IBM authorized
> minipci WIFI card without Bios modification.
>
> See
> http://www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card
The misc/tpwireless port can help work
However, this won't be easy at all. The driver has almost no control over
> this hardware. Most things are handled inside the firmware and we cannot
> look inside. The driver only sees a single bit which says "a fatal error
> occured" with no further information available.
>
.
However, this won't be easy at all. The driver has almost no control over
this hardware. Most things are handled inside the firmware and we cannot
look inside. The driver only sees a single bit which says "a fatal error
occured" with no further information available.
The driver tri
On 3/2/18, Stefan Sperling wrote:
> On Fri, Mar 02, 2018 at 12:14:14PM +, Xianwen Chen wrote:
>> Dear OpenBSD users,
>>
>> I am running OpenBSD 6.2 i386 on ThinkPad R52. The system has been
>> complaining "iwi0: fatal firmware error" in the past two or thr
On Fri, Mar 02, 2018 at 12:14:14PM +, Xianwen Chen wrote:
> Dear OpenBSD users,
>
> I am running OpenBSD 6.2 i386 on ThinkPad R52. The system has been
> complaining "iwi0: fatal firmware error" in the past two or three
> days. I was not aware of the problem before t
Dear OpenBSD users,
I am running OpenBSD 6.2 i386 on ThinkPad R52. The system has been
complaining "iwi0: fatal firmware error" in the past two or three
days. I was not aware of the problem before that.
The problem can usually be worked around by "ifconfig iwi0 -inet
-wpakey -nwke
OpenBSD 6.2 hw support in this laptop (Thinkpad
>> T460p)
>
>
> What does running "fw_update" do? I run OpenBSD fine with my 915.
> I did not have to download anything from intel.
The inteldrm firmware isn't linked to the build, so there are no packages for
fw_update to use.
Hello Riccardo,
# fw_update -i
Installed: uvideo-firmware-1.2p2 iwm-firmware-0.20170105
vmm-firmware-1.10.2p4
Running 'fw_upfdate -a' did not helped
inteldrm was doing well also here:
#dmesg | grep drm
nteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 530" rev 0x
Hi,
On 2018-01-02 14:04:20 +0100 Luca Franchini wrote:
I have downloaded skl_dmc_ver1.bin from Intel site.
Is there a chance to have it loaded?
Better power saving?
I'm very happy with OpenBSD 6.2 hw support in this laptop (Thinkpad
T460p)
What does running "fw_update" do? I run OpenBSD f
1 - 100 of 456 matches
Mail list logo
