I am using hrev52174 and my broadcom 440x nic doesn’t configure, it just keeps saying “configuring” but nothing happens. It seems to be related to this bug: https://dev.haiku-os.org/ticket/14281
my ethernet Broadcom4401-BO device:170c doesn’t work at all…
you can try to toggle between dhcp and static in the network preferences…
How do I do this? I don’t see any option in network prefs.
The IPv4 protocol under your device has a “Mode” for DHCP|static.
Unfortunately I have sort of the same problem. Broadcom 440x keeps reconnecting as soon as I start using webpositive. I remember that this issue existed already for years… This is my laptop I used to bring to BeGeistert. On current nightly (as of yesterday) I see that it’s even worse now: as soon as I connect a cable (it gets an IPV4 adress via DHCP, 100mbit, and I can briefly browse the web, intermittently) I run high risk of a system hang. I have to hard power down the laptop. Happens always after a second upto a minute. Also happens when using vision for example, or as soon as I start the update check app.
On older versions of Haiku (i.e. 2015, 2016) the reconnection thing occurs also, but no system freeze as far as I remember.
Ah OK, I have to correct myself: on hrev49918 which I still also have on that laptop ethernet seems to work correctly. No reconnects, no system hangs.
Could you try to copy Broadcom driver from hrev49918 and see if it works on your current nightly?
Ah, good plan, I’ll get back to you in half an hour…
Yeah, good plan indeed. Stable.
Any more suggestions? Or can someone start a hunt? I can quickly test drivers, prefereably if the binary can be sent directly to me
BTW: the laptop does not aquire an IPV6 adress, but my provider and local network supports it (seeing it work on other systems (android, windows).
Typing this message from the laptop.
Update: I see it’s a BSD driver, so I guess the glue is a probable source of the trouble? I see that in glue.c ‘FBSD_FAST_TASKQUEUE’ is removed (commented out). Could that be it? (I might be saying stupid things here, I don’t know of course…)
I guess one would have to check what has changed in the driver and glue code:
Also, each BSD driver contains freebsd compat lib builtin:
UPD: fixed compat link
hmm, that’s quite a lot afaict.
It’s not the FAST_TASKQUEUE, that I just tested explicitly.
I think I’ll just try a few hrevs from the nightly page, though the oldest one just -might- be too new…
If I find more, I’ll let you know. Thanks for the pointers!
This somewhat makes me wish that pkgman had a function to explicitly install older revs to test, perhaps also a boot order based on a construct similar to git bisect
Indeed something like that could be very handy. Doing this by hand is not so nice.
Anyhow: tried hrev53509 but this one fails to boot (hangs at last icon, and also in vesa mode driver)
Tried hrev53995 which only boots with the vesa driver, but when I network with it I see the system hang.
So the problem was introduced with or before hrev53995, but after hrev49918 which works nicely, including the nvidia gfx driver.
The laptop has a 32bit intel processor, so I’m always running 32bit versions of Haiku.
I think it was disabled in https://git.haiku-os.org/haiku/commit/?id=hrev45736
See also other IPV6 issues:
Ah thanks, that clears it up for me. That’s better than having lots of crashes
In the meantime I was able to boot href53623, with vesa graphics as otherwise it gets stuck at the last pictogram before/when the modeswitch comes up.
Network crashes. So the problem arised with/before href 53623 (20191208).
I’ll leave it at that for now. Thanks for your support today!
Oh BTW the original reporter(?) of ticket #14281 mentioned hrev52091 with (I think) this same problem.
Maybe he also tested a recent one before that without problems… hmm, at least the gap is becoming smaller as I saw it working OK with hrev49918…
I have updated the ticket. It turns out that the driver I mentioned works OK on mains power, but not on battery power (CPU running much slower and time running much faster).