| 1 |
On Sunday 13 Apr 2014 01:01:53 Nikos Chantziaras wrote: |
| 2 |
> On 12/04/14 18:53, Peter Humphrey wrote: |
| 3 |
--->8 |
| 4 |
> > Has anyone got =net-misc/r8168-8.028.00::gentoo to compile? |
| 5 |
> > [...] |
| 6 |
> > Can anyone advise me how to proceed here? I've been using the in-kernel |
| 7 |
> > R8169 module with no problems until I installed Snort, but now I have to |
| 8 |
> > keep issuing "ethtool -K eth0 gro off" every minute |
| 9 |
> |
| 10 |
> I had similar problems until I discovered that the in-kernel R8169 |
| 11 |
> driver actually tries to load firmware from disk. That firmware wasn't |
| 12 |
> there. If that is your problem, then this: |
| 13 |
> |
| 14 |
> dmesg | grep -i firmware |
| 15 |
> |
| 16 |
> would print something like: |
| 17 |
> |
| 18 |
> r8169 [...]: unable to load firmware patch rtl_nic/rtl8168e-3.fw |
| 19 |
|
| 20 |
Here's a snippet from dmesg: |
| 21 |
|
| 22 |
[ 0.053557] ACPI: bus type PCI registered |
| 23 |
[ 0.054231] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem |
| 24 |
0xe0000000-0xefffffff] (base 0xe0000000) |
| 25 |
[ 0.054475] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820 |
| 26 |
[ 0.055024] PCI: Using MMCONFIG for extended config space |
| 27 |
[ 0.055196] PCI: Using configuration type 1 for base access |
| 28 |
[ 0.082221] bio: create slab <bio-0> at 0 |
| 29 |
[ 0.083189] ACPI: Added _OSI(Module Device) |
| 30 |
[ 0.083367] ACPI: Added _OSI(Processor Device) |
| 31 |
[ 0.083531] ACPI: Added _OSI(3.0 _SCP Extensions) |
| 32 |
[ 0.084031] ACPI: Added _OSI(Processor Aggregator Device) |
| 33 |
[ 0.087597] ACPI: EC: Look up EC in DSDT |
| 34 |
[ 0.092258] ACPI: Executed 1 blocks of module-level executable AML code |
| 35 |
[ 0.103159] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored |
| 36 |
|
| 37 |
and another: |
| 38 |
|
| 39 |
[ 5.232622] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded |
| 40 |
[ 5.233183] r8169 0000:01:00.0: irq 45 for MSI/MSI-X |
| 41 |
[ 5.233963] r8169 0000:01:00.0 eth0: RTL8168d/8111d at 0xf8170000, |
| 42 |
70:71:bc:94:ee:71, XID 081000c0 IRQ 45 |
| 43 |
[ 5.233988] r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx |
| 44 |
checksumming: ko] |
| 45 |
[ 5.291801] intel_rng: Firmware space is locked read-only. If you can't or |
| 46 |
intel_rng: don't want to disable this in firmware setup, and if |
| 47 |
intel_rng: you are certain that your system has a functional |
| 48 |
intel_rng: RNG, try using the 'no_fwh_detect' option. |
| 49 |
|
| 50 |
I suppose I can assume a functional RNG - or can I? I'll try adding |
| 51 |
intel_rng=no_fwh_detect to my kernel command line next time I reboot. |
| 52 |
|
| 53 |
Later: I've booted with that intel_rng command and I'm watching to see how it |
| 54 |
goes. |
| 55 |
|
| 56 |
> Solution to the problem was fairly simple. I just emerged this package: |
| 57 |
> |
| 58 |
> sys-kernel/linux-firmware |
| 59 |
|
| 60 |
Yes, I have that package installed, and the network has been as solid as |
| 61 |
yours. I just have this problem with the card insisting on doing generic |
| 62 |
receive offload and thereby confusing Snort. |
| 63 |
|
| 64 |
Later still: no improvement. So thank you all for your help, but pro tem I'm |
| 65 |
going to abandon Snort as being just too much trouble. Maybe an outfit like |
| 66 |
Alan McK's could afford the time but it's too heavy for home use. |
| 67 |
|
| 68 |
Pity. I'll have to look around for a lighter IDS. |
| 69 |
|
| 70 |
-- |
| 71 |
Regards |
| 72 |
Peter |
Archives