Route Metric
by Alexander Bahoor
Greetings,
Route metric is a variable that a router uses to choose the best route to a destination. Depending on the routing protocol, the metric definition is different. What I'm trying to understand is how Linux defines the metric in the route output command.
For example when a Fedora laptop has two active interfaces, Ethernet and wifi, the metric in route output, is set to 1 for Ethernet and 2 for WiFi. Reading the man page on the route command, it says the metric is defined as hop counts to a destination. Based on the above observation, this is incorrect or incomplete. It definitely include the hop count, but how fedora came up with 1 and 2. Could it be just used these number arbitrarily to indicate to IP, that the Ethernet interface is the preferred path to use to send traffic, because it's speed is faster and more reliable?
Basically what I'm looking for is the definition of the metric defintion in Linux or Fedora. And if someone shed light on the windows definition that would be great.
Rgrds,
Alex
12 years, 4 months
avoiding taint for integrated compate-wireless modules
by John W. Linville
So we had the compat-wireless package integrated into the Rawhide
kernel builds for a while. Then it was pointed-out that due to
upstream commit 2449b8ba0745327c5fa49a8d9acffe03b2eded69, these modules
were tainting the kernel with TAINT_OOT_MODULE. In response to that, I
turned-off the compat-wirelss bits to give myself a chance to regroup.
Today I posted an RFC patch on LKML, but I doubt if it will get
merged upstream:
http://marc.info/?l=linux-kernel&m=132387980907398&w=2
Anyway, it resolves the taint issue for the integrated compat-wireless
build.
I did a test kernel build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3585146
Is anyone going to puke on my shoes if I add this patch to Fedora
and reenable the integrated compat-wireless builds?
John
--
John W. Linville The water won't run clean until you get
linville(a)redhat.com the pigs out of the creek.
12 years, 4 months
[PATCH 0/2] Enable new keyring based id mapper for NFSv4
by Steve Dickson
These two patches will enable the new id mapper
that uses the key-request up-call mechanism
and uses the keyring to store the ids.
The up-call is made to the user level program
/usr/sbin/nfsidmap which does all the actual
id mapping. Using this mechanism will mean
the rpc.idmapd daemon will no longer be needed
on the NFS client.
Now here is the trick... nfs-utils-1.2.5-7.fc17
has to be installed since it installs the correct
user level files to make all this work. If that
version is not install, the owner of all the files
on NFSv4 mounts will be our friend, Mr. nobody
Note, the key ring patch is a combination of two
patches that are currently swimming their way upstream.
Its needed because, if by chance, our friend Mr. nobody
does end up own some files, the key ring can be
manipulated (by nfsidmap) so a new id mapping can be created.
Steve Dickson (2):
Enabled the in-kernel idmapper.
keyring: allow special keyrings to be cleared
config-generic | 2 +-
kernel.spec | 6 ++
linux-3.1-keys-remove-specal-keyring.patch | 110 ++++++++++++++++++++++++++++
3 files changed, 117 insertions(+), 1 deletions(-)
create mode 100644 linux-3.1-keys-remove-specal-keyring.patch
--
1.7.7.3
12 years, 4 months
3.1.5 & bluetooth problem
by Genes MailLists
I booted 3.1.5 (on F15 compiled from f16 source) - and bluetooth on my
lenovo laptop stopped working - the hardware light did not light up on
boot - booting back to 3.1.4 and it works fine.
I didn't see anything interesting in the boot log ...
lsusb shows on 3.1.5 showed no BT device - on 3.1.4 I see this:
Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a5c Broadcom Corp.
idProduct 0x217f Bluetooth Controller
bcdDevice 7.48
iManufacturer 1 Broadcom Corp
iProduct 2 Broadcom Bluetooth Device
iSerial 3 EC55F9F14499
bNumConfigurations 1
Anyone else having any BT problems with 3.1.5 ?
thanks
gene
12 years, 4 months
Status of analog module in 3.2?
by Bruno Wolff III
I noticed today when trying out a 3.2 kernel (I have been using 3.1 kernels
in rawhide for a couple of reasons) that the analog module is no longer
available. The driver does not seem to be built in either as I am not
seeing a joystick device for my game pad.
Is this an oversight or is the plan to drop that module going forward?
12 years, 4 months
thoughts on modules-extra subpackage...
by John W. Linville
I'm sorry I missed the original discussion thread. I was blinded by
my birthday and the Thanksgiving holiday. :-) That, and I've been
chipping away to get the compat-wireless bits shaped-up for proper
Fedora integration...
Actually, the latter is what brought modules-extra to my attention.
My changes cause ssb to not be built in the main kernel tree.
For some reason, ssb got added to mod-extra.list. So, the combination
of modules-extra and my changes resulted in a broken build. FWIW,
I think that fix is simple -- I don't think ssb should have been in
that list in the first place.
So that brings me to the first big concern... Should we have _any_
hardware enablement included in the modules-extra package? If so,
what is the cut-off? Do we really want to diminish our out-of-the-box
hardware support for whatever benefit modules-extra provides?
Is there SMOLT data or something similar to justify the list of
modules being moved?
Two other big chunks of the module-extras package are TCP congestion
control algorithms and network queueing disciplines. These two
types of modules come immediately into play when someone is trying
to tune the performance of their networks. If anything, we should
be encouraging their use, not making them more invisible. So, I'm
wondering why these got put into the mod-extra.list file?
As for the stated benefits... I'm skeptical of the security argument.
I mean, I can believe that a module could get accidentally or
inadvertantly loaded and then exploited. I just think that closing
those holes is a better plan. Also, I find the size argument
unconvincing as well. I just don't think a couple of megs of storage
savings amounts to much these days, especially if you create confusion
or remove functionality in the process. The cruft argument is the
most reasonable for at least some of the modules in the list, but
I'm not sure it is sufficient to justify the confusion and churn.
So anyway, just in case you were wondering about my opinion... :-)
John
--
John W. Linville The water won't run clean until you get
linville(a)redhat.com the pigs out of the creek.
12 years, 4 months
GMA500
by Bodhi Zazen
There is support for the intel GMA500 in the staging drivers. It offers decent 2d support, but not 3d.
The driver is close to being in the main stream kernel, so I would like to request it be build as a module.
There is one "SNAFU" , the staging driver, psb_gfx, conflicts with the "polusbo" kernel module (CONFIG_STUB_POULSBO=m)
So if you enable the staging driver, you need to disable the CONFIG_STUB_POULSBO=m
CONFIG_STUB_POULSBO=n
CONFIG_DRM=y # or module
CONFIG_DRM_PSB=m
The name of the staging driver varies, in the 3.2.0-rc3 it is DRM_PSB (I think similar names in other, older kernels as well).
With those (small) configuration changes the GMA500 , 2d graphics will work out of the box (rather then having X fail).
To be honest, I do not think the STUB_POULSBO is used by any other hardware.
I will be filing a bug report on the stub driver and conflicts with psb_gfx with kernel.org (upstream).
Thank you.
12 years, 4 months
[RFC] kernel.spec: reverse dependency logic for moving packages between kernel and kernel-modules-extra
by John W. Linville
The logic to process mod-extra.list finds modules that depend on
the modules in that list and includes those in kernel-module-extra
as well. This logic is broken, because it does not account for
multi-layer dependency chains. Specifically, if a module depends
on another module, and only the second one depends on something in
mod-extra.list, then only the second would get moved. This leaves the
first module in the kernel package, resulting in WARNING messages
when the kernel rpm is installed:
Preparing... ########################################### [100%]
1:kernel ########################################### [100%]
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_register_driver
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2fc/bnx2fc.ko needs unknown symbol cnic_unregister_driver
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_register_driver
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/scsi/bnx2i/bnx2i.ko needs unknown symbol cnic_unregister_driver
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_reset_all
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_handle_dn
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbd
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol __wusb_dev_get_by_usb_dev
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusbhc_giveback_urb
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/wusbcore/wusb-wa.ko needs unknown symbol wusb_dev_destroy
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_disconnect
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/drivers/usb/atm/xusbatm.ko needs unknown symbol usbatm_usb_probe
WARNING: /lib/modules/3.2.0-0.rc3.git1.2.fc14.x86_64/kernel/net/bridge/netfilter/ebtable_broute.ko needs unknown symbol br_should_route_hook
This patch reverses that logic, so that anything in kernel with
a dependency on something in mod-extra.list will cause the module
in mod-extra.list to be treated as if it was _not_ in that list.
This prevents the WARNING lines above.
Signed-off-by: John W. Linville <linville(a)tuxdriver.com>
---
I don't think I'm very fond of the kernel-modules-extra package.
But if it is going to be around, it needs to process the dependencies
in a way that doesn't require both modules to be installed all the
time. :-)
diff --git a/kernel.spec b/kernel.spec
index e1cf978..136d50f 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1661,6 +1662,7 @@ BuildKernel() {
# Look through all of the modules, and throw any that have a dependency in
# our list into the list as well.
rm -rf dep.list dep2.list
+ rm -rf req.list req2.list
cp %{SOURCE16} .
for dep in `cat modnames`
do
@@ -1673,12 +1675,16 @@ BuildKernel() {
then
continue
else
- echo $dep >> dep.list
+ echo $mod.ko >> req.list
fi
done
done
- for mod in `cat mod-extra.list`
+ sort -u req.list > req2.list
+ sort -u mod-extra.list > mod-extra2.list
+ join -v 1 mod-extra2.list req2.list > mod-extra3.list
+
+ for mod in `cat mod-extra3.list`
do
# get the path for the module
modpath=`grep /$mod modnames`
@@ -1696,7 +1702,8 @@ BuildKernel() {
mv $mod $newpath
done
- rm modnames mod-extra.list dep.list dep2.list
+ rm modnames dep.list dep2.list req.list req2.list
+ rm mod-extra.list mod-extra2.list mod-extra3.list
popd
# remove files that will be auto generated by depmod at rpm -i time
--
John W. Linville The water won't run clean until you get
linville(a)redhat.com the pigs out of the creek.
12 years, 4 months
[RFC PATCH] Add modules-extra subpackage
by Josh Boyer
Below is the first swag at a kernel-modules-extra package. It seems to
do the proper thing, and move the listed modules to the
/lib/modules/`uname -r`/extra/ directory[1], and then package those up into
a kernel-<flavor>-modules-extra subpackage. I have a scratch build with
this change here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3523738
The macros the define the kernel-modules-extra subpackage and %files
sections look nasty, but they are required for when we build multiple
kernel flavors (e.g. PAE, debug, etc) so we get the proper per-flavor
subpackage.
The mod-extra.list file is the configuration file for which modules
should be put into the modules-extra subpackage. This isn't a fully
comprehensive list of exactly what will wind up in the subpackage.
Instead, it is a somewhat higher level list and the code will go through
and also put anything with a dependency[2] on one of these modules into the
subpackage as well (e.g. listing wimax.ko will also get
wimax/i2400m/i2400m.ko pulled in).
Comments welcome.
josh
[1] The extra/ directory already exists and is set aside for "out of tree"
modules, so we're slightly overriding the intention by sticking modules that
are built in-tree there. However, we do consider these modules _extra_ and
it seemed silly to create yet another directory for this purpose.
[2] The dependency stuff is a poor-man's depmod, which isn't run until
after the kernel package is installed. It's a best effort really, not
100% comprehensive but it seems to catch most things. We could run
depmod here and then use those results to catch everything but I wasn't
sure if that was desired or required.
---
kernel.spec | 69 ++++++++++++++++++++++-
mod-extra.list | 170 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 238 insertions(+), 1 deletions(-)
create mode 100644 mod-extra.list
diff --git a/kernel.spec b/kernel.spec
index b72afb3..9eadbb1 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -548,6 +548,7 @@ Source1: compat-wireless-%{cwversion}.tar.bz2
Source11: genkey
Source14: find-provides
Source15: merge.pl
+Source16: mod-extra.list
Source19: Makefile.release
Source20: Makefile.config
@@ -902,6 +903,24 @@ against the %{?2:%{2} }kernel package.\
%{nil}
#
+# This macro creates a kernel-<subpackage>-modules-extra package.
+# %%kernel_modules-extra_package <subpackage> <pretty-name>
+#
+%define kernel_modules-extra_package() \
+%package %{?1:%{1}-}modules-extra\
+Summary: Extra kernel modules to match the %{?2:%{2} }kernel\
+Group: System Environment/Kernel\
+Provides: kernel%{?1:-%{1}}-modules-extra-%{_target_cpu} = %{version}-%{release}\
+Provides: kernel-modules-extra-%{_target_cpu} = %{version}-%{release}%{?1:.%{1}}\
+Provides: kernel-modules-extra = %{version}-%{release}%{?1:.%{1}}\
+Provides: kernel-modules-extra-uname-r = %{KVERREL}%{?1:.%{1}}\
+Requires: kernel%{?1:-%{1}}-%{_target_cpu} = %{version}-%{release}%{?1:.%{1}}\
+AutoReqProv: no\
+%description -n kernel%{?variant}%{?1:-%{1}}-modules-extra\
+This package provides less commonly used kernel modules for the %{?2:%{2} }kernel package.\
+%{nil}
+
+#
# This macro creates a kernel-<subpackage> and its -devel and -debuginfo too.
# %%define variant_summary The Linux kernel compiled for <configuration>
# %%kernel_variant_package [-n <pretty-name>] <subpackage>
@@ -912,12 +931,14 @@ Summary: %{variant_summary}\
Group: System Environment/Kernel\
%kernel_reqprovconf\
%{expand:%%kernel_devel_package %1 %{!?-n:%1}%{?-n:%{-n*}}}\
+%{expand:%%kernel_modules-extra_package %1 %{!?-n:%1}%{?-n:%{-n*}}}\
%{expand:%%kernel_debuginfo_package %1}\
%{nil}
# First the auxiliary packages of the main kernel package.
%kernel_devel_package
+%kernel_modules-extra_package
%kernel_debuginfo_package
@@ -1645,6 +1666,50 @@ BuildKernel() {
rm -f modinfo modnames
+ pushd $RPM_BUILD_ROOT/lib/modules/$KernelVer/
+ rm -rf modnames
+ find . -name "*.ko" -type f > modnames
+ # Look through all of the modules, and throw any that have a dependency in
+ # our list into the list as well.
+ rm -rf dep.list dep2.list
+ cp %{SOURCE16} .
+ for dep in `cat modnames`
+ do
+ depends=`modinfo $dep | grep depends| cut -f2 -d":" | sed -e 's/^[ \t]*//'`
+ [ -z "$depends" ] && continue;
+ for mod in `echo $depends | sed -e 's/,/ /g'`
+ do
+ match=`grep "^$mod.ko" mod-extra.list` ||:
+ if [ -z "$match" ]
+ then
+ continue
+ else
+ echo $dep >> dep.list
+ fi
+ done
+ done
+
+ for mod in `cat mod-extra.list`
+ do
+ # get the path for the module
+ modpath=`grep /$mod modnames`
+ [ -z "$modpath" ] && continue;
+ echo $modpath >> dep.list
+ done
+
+ sort -u dep.list > dep2.list
+
+ # now move the modules into the extra/ directory
+ for mod in `cat dep2.list`
+ do
+ newpath=`dirname $mod | sed -e 's/kernel\//extra\//'`
+ mkdir -p $newpath
+ mv $mod $newpath
+ done
+
+ rm modnames mod-extra.list dep.list dep2.list
+ popd
+
# remove files that will be auto generated by depmod at rpm -i time
for i in alias alias.bin builtin.bin ccwmap dep dep.bin ieee1394map inputmap isapnpmap ofmap pcimap seriomap symbols symbols.bin usbmap
do
@@ -2061,7 +2126,6 @@ fi
/lib/modules/%{KVERREL}%{?2:.%{2}}/kernel\
/lib/modules/%{KVERREL}%{?2:.%{2}}/build\
/lib/modules/%{KVERREL}%{?2:.%{2}}/source\
-/lib/modules/%{KVERREL}%{?2:.%{2}}/extra\
/lib/modules/%{KVERREL}%{?2:.%{2}}/updates\
%if %{with_backports}\
/lib/modules/%{KVERREL}%{?2:.%{2}}/backports\
@@ -2075,6 +2139,9 @@ fi
%{expand:%%files %{?2:%{2}-}devel}\
%defattr(-,root,root)\
/usr/src/kernels/%{KVERREL}%{?2:.%{2}}\
+%{expand:%%files %{?2:%{2}-}modules-extra}\
+%defattr(-,root,root)\
+/lib/modules/%{KVERREL}%{?2:.%{2}}/extra\
%if %{with_debuginfo}\
%ifnarch noarch\
%{expand:%%files -f debuginfo%{?2}.list %{?2:%{2}-}debuginfo}\
diff --git a/mod-extra.list b/mod-extra.list
new file mode 100644
index 0000000..faec1d8
--- /dev/null
+++ b/mod-extra.list
@@ -0,0 +1,170 @@
+aer_inject.ko
+yenta_socket.ko
+tcp_bic.ko
+tcp_westwood.ko
+tcp_htcp.ko
+tcp_highspeed.ko
+tcp_hybla.ko
+tcp_vegas.ko
+tcp_scalable.ko
+tcp_lp.ko
+tcp_veno.ko
+tcp_yeah.ko
+tcp_illinois.ko
+dccp_diag.ko
+dccp_ipv4.ko
+dccp_ipv6.ko
+dccp.ko
+dccp_probe.ko
+sctp.ko
+sctp_probe.ko
+rds.ko
+rds_rdma.ko
+rds_tcp.ko
+atm.ko
+br2684.ko
+clip.ko
+lec.ko
+pppoatm.ko
+l2tp_core.ko
+l2tp_debugfs.ko
+l2tp_eth.ko
+l2tp_ip.ko
+l2tp_netlink.ko
+l2tp_ppp.ko
+8021q.ko
+llc.ko
+ipx.ko
+appletalk.ko
+ipddp.ko
+wanrouter.ko
+phonet.ko
+pn_pep.ko
+af_802154.ko
+ieee802154.ko
+sch_atm.ko
+sch_cbq.ko
+sch_choke.ko
+sch_drr.ko
+sch_dsmark.ko
+sch_gred.ko
+sch_hfsc.ko
+sch_htb.ko
+sch_ingress.ko
+sch_mqprio.ko
+sch_multiq.ko
+sch_netem.ko
+sch_prio.ko
+sch_qfq.ko
+sch_red.ko
+sch_sfb.ko
+sch_sfq.ko
+sch_tbf.ko
+sch_teql.ko
+ax25.ko
+netrom.ko
+rose.ko
+6pack.ko
+baycom_par.ko
+baycom_ser_fdx.ko
+baycom_ser_hdx.ko
+bpqether.ko
+hdlcdrv.ko
+mkiss.ko
+yam.ko
+can.ko
+can-raw.ko
+can-bcm.ko
+can-dev.ko
+slcan.ko
+vcan.ko
+c_can.ko
+c_can_platform.ko
+ems_pci.ko
+kvaser_pci.ko
+plx_pci.ko
+sja1000.ko
+sja1000_platform.ko
+softing_cs.ko
+softing.ko
+ems_usb.ko
+esd_usb2.ko
+wimax.ko
+nfc.ko
+nci.ko
+mtd.ko
+mptbase.ko
+mptctl.ko
+mptfc.ko
+i2400m.ko
+hisax.ko
+hysdn.ko
+isdn.ko
+mISDN_core.ko
+mISDN_dsp.ko
+capi.ko
+dss1_divert.ko
+bas_gigaset.ko
+gigaset.ko
+avm_cs.ko
+b1.ko
+diva_idi.ko
+divas.ko
+avmfritz.ko
+hfcpci.ko
+hfcmulti.ko
+netjet.ko
+w6692.ko
+avma1_cs.ko
+elsa_cs.ko
+hfc4s8s_l1.ko
+joydev.ko
+a3d.ko
+adi.ko
+analog.ko
+cobra.ko
+db9.ko
+gamecon.ko
+gf2k.ko
+grip.ko
+grip_mp.ko
+guillemot.ko
+iforce.ko
+interact.ko
+joydump.ko
+magellan.ko
+sidewinder.ko
+spaceball.ko
+spaceorb.ko
+stinger.ko
+tmdc.ko
+turbografx.ko
+twidjoy.ko
+walkera0701.ko
+warrior.ko
+xpad.ko
+zhenhua.ko
+trancevibrator.ko
+umc.ko
+uwb.ko
+whci.ko
+hwa-rc.ko
+uio.ko
+uio_aec.ko
+uio_pci_generic.ko
+jfs.ko
+gfs2.ko
+ocfs2.ko
+ocfs2_stackglue.ko
+ocfs2_dlm.ko
+cuse.ko
+affs.ko
+befs.ko
+jffs2.ko
+ubifs.ko
+sysv.ko
+ufs.ko
+ncpfs.ko
+coda.ko
+9p.ko
+9pnet.ko
--
1.7.7.1
12 years, 4 months
