#2767 closed enhancement (fixed)
if_re port from freebsd
Reported by: | nopper | Owned by: | jackburton |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Network | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
This is the port of if_re freebsd network driver.
Tested on msi wind subnotebook.
Attachments (1)
Change History (14)
comment:1 by , 16 years ago
comment:3 by , 16 years ago
Replying to nielx:
Do you get any error message whilst attaching the files?
Exception: Failed to create unique name: /var/trac/dev.haiku-os.org/attachments/ticket/2767/if_re_port.100.diff
comment:5 by , 16 years ago
Owner: | changed from | to
---|
I'd like to commit this. We already have a native driver which supports some kinds of RTL8169 cards, But as this driver supports much more (also the card on my laptop, which isn't supported by the other driver), I'm for committing it into the tree. We could also choose to integrate (later) the necessary changes into our own native driver.
comment:6 by , 16 years ago
Status: | new → assigned |
---|
update: While testing the driver on my laptop, I found that after a while, the cpu activity goes to 100% (only for one cpu, the other is idle) and the system becomes completely unresponsive (yeah, not even F12 works anymore). Top shows that the thread "fast taskq" is getting all the cpu load. Could be a problem related to the dual core cpu, or some other thing. I'm still for committing the driver, I'll just not include it by default in the image.
comment:7 by , 16 years ago
Oh, I forgot: Removing the ethernet cable makes the cpu utilization go back to normal.
comment:8 by , 16 years ago
Still one more thing: Disabling one core makes the system work flawlessly. At least I can develop under haiku now.
follow-up: 10 comment:9 by , 16 years ago
If a native driver is available, I would always prefer it, as it is easier to debug, and is more efficient. But since our rtl8169 driver currently doesn't support the chipset, I wouldn't mind adding it for now - with a more descriptive name, and with the already supported chipsets disabled, maybe.
comment:10 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Replying to axeld:
If a native driver is available, I would always prefer it, as it is easier to debug, and is more efficient. But since our rtl8169 driver currently doesn't support the chipset, I wouldn't mind adding it for now - with a more descriptive name, and with the already supported chipsets disabled, maybe.
Oops! too late, I already committed it in hrev27843! :) What do you mean with "a more descriptive name" ? The name of the jam target ? Do you think we should add it to the image by default ? I'm more and more thinking that the problem I'm having isn't directly related to this driver, but more to the freebsd compat layer or to the scheduler.
I'll also disable the already supported chipset.
follow-up: 12 comment:11 by , 16 years ago
A more descriptive driver name than "re". That name doesn't really tell what chips are supported, if it's a audio/graphics/whatever driver. The other drivers are named like eg rtl8139, a little more descriptive IMO.
comment:12 by , 16 years ago
Replying to ekdahl:
A more descriptive driver name than "re". That name doesn't really tell what chips are supported, if it's a audio/graphics/whatever driver. The other drivers are named like eg rtl8139, a little more descriptive IMO.
Of course, I got that :) I meant: Should I only change the jam target name/binary name, or also the directory where the driver is stored ?
comment:13 by , 16 years ago
It's all or nothing IMO, or else no one will understand our directory hierarchy anymore one day; you can just use "svn mv" to rename the directory.
Replying to nopper:
Cannot attach files. BTW the patch is here: http://snippets.pornosecurity.org/files/if_re_port.diff