bugzilla triage.
by Dave Jones
The current state of bugzilla for the kernel is pretty depressing.
Counting in all the bugs we never fixed for FC5 (a lot of which
are probably still valid for everything through to rawhide),
there are around 1600 open bugs.
In an attempt to disperse some of the 'triage' type work to volunteers,
I've started a page at http://fedoraproject.org/wiki/KernelBugTriage
with some simple things that people can do to help out.
Any additions/improvements welcomed.
Dave
--
http://www.codemonkey.org.uk
16 years
-vanilla builds.
by Dave Jones
I'd like to move forward on us getting vanilla builds out for testers.
There are a couple things worth thinking about, which I'd like other
peoples thoughts on.
* The location of the binaries - I think we ended up settling
on putting them on people.fedoraproject.org.
Given the 150MB quota, this probably means...
- no -debuginfo packages. (not a huge deal)
- probably just x86/x86-64 to begin with.
- probably no non-debug variants (ie, same model
as rawhide, with debug 'always on'
- worth doing PAE and non-PAE ? just one? which?
* how/where to building them.
AFAIK, it isn't possible to pass switches like --with-vanilla
to koji, so the two options are..
- build vanilla as part of the regular build
(not a great idea, it already takes hours to build
a complete set of kernels).
- I kick off a bunch of rpmbuilds locally and push them
by hand. (scriptable at least, so not such a big deal).
I think this is the best option.
* frequency of updates.
I don't think it's really worthwhile doing daily builds.
Doing at least one per -rc is probably a good target,
with perhaps a -rcN-git build periodically if the next
-rc is taking a while to land.
* dependancies.
This is the only remaining technical puzzle I think.
I'd like the vanilla rpms to install on FC6, F7, and rawhide.
Doing separate builds per distro is just going to kill me.
The only thing stopping this from working is requires: lines
like ..
%define kernel_prereq fileutils, module-init-tools, initscripts >= %8.11.1-1, mkinitrd >= 6.0.9-7
I'm thinking perhaps something like..
%if ! %{with_vanilla}
%define kernel_prereq fileutils, module-init-tools, initscripts >= %8.11.1-1, mkinitrd >= 6.0.9-7
%else
%define kernel_prereq fileutils, module-init-tools, initscripts, mkinitrd
%endif
might do the trick.
However for some cases, those versioned dependancies are there for a reason, and I'm
not entirely sure what to do about them. I'd rather not have to
build non-kernel packages for the vanilla repo too.
Ideas ?
Ideally I'd like to get to a state where these are built
by a cronjob on my desktop that checks for a new rc,
and uploads new updates whilst I sleep^Wdo something else.
Dave
--
http://www.codemonkey.org.uk
16 years
[RFC PATCH] lirc IR receiver drivers
by Jarod Wilson
Hey all,
So... As I've mentioned on various forums here and there in the recent
past, I'd really like to see fedora carry the lirc drivers
(http://www.lirc.org/) in-kernel, and help push them into the upstream
kernel. I finally got around to doing something significant about it
this evening. The link below is the completion of my first attempt at a
patch tailored for upstream, based partially on work done by Mario
Limonciello for Ubuntu (cc'd).
http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch
It includes all the latest bits from lirc cvs, save the lirc_gpio
driver, which doesn't compile of late, but restructures the code in a
few ways:
1) header include paths have been altered to match the file layout as
patched into the kernel tree
2) in theory, all '#if LINUX_VERSION_CODE' and similar bits have been
eliminated, along with all code sections for older kernels dropped,
which trims down the patch by over 1000 lines and definitely makes it
more manageable.
3) a few minor changes from the upstream code base to compile with the
latest rawhide gcc (a few "error: void value not ignored as it ought to
be" messages, which I've not yet properly fixed).
--
I've done a local x86_64 test build with this patch against
2.6.23-rc3-git6, which upon initial inspection, looks good, though I
have yet to try it out on actual hardware (on my todo list this
weekend). See resulting build file listing below.
If deemed appropriate, I'd like to slap this patch into the rawhide
kernel builds as soon as possible. Would also rather like to get it into
F7 and FC6 kernels after its had a bit of soak time...
Next up, I'd like to get the patch broken up into manageable chunks and
sent off to lkml for review so we can get this thing up to kernel coding
standards and hopefully included in the kernel proper.
$ rpm -qpl RPMS/x86_64/kernel-2.6.23-0.133.rc3.git6.lirc1.fc8.x86_64.rpm
| grep -e 'lirc_.*.ko'
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_atiusb/lirc_atiusb.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_bt829/lirc_bt829.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/commandir.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/lirc_cmdir.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_dev/lirc_dev.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_i2c/lirc_i2c.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_igorplugusb/lirc_igorplugusb.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_imon/lirc_imon.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_it87/lirc_it87.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb/lirc_mceusb.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb2/lirc_mceusb2.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_pvr150/lirc_pvr150.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_serial/lirc_serial.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_sir/lirc_sir.ko/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc7/kernel/drivers/input/lirc/lirc_streamzap/lirc_streamzap.ko
/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_ttusbir/lirc_ttusbir.ko
Thanks for listening, time for z's...
--
Jarod Wilson
jwilson(a)redhat.com
16 years
The NFS "nosharecache" patch in F7 is broken
by Chuck Ebbert
If people try mounting several exports from the same filesystem, it fails
with confusing error messages if the mount options are different for some
of the mount points. Adding "nosharecache" to the mount options fixes that,
but people with working setups suddenly find they need this new option to
use a setup that used to work without it. Should we just revert that patch?
16 years
Need to use i586 kernel and i386 glibc for via c7 epia system
by Hans de Goede
Hi all,
A bit offtopic for this list, but this is the best place I could think of to
discuss this.
A friend of mine had trouble with 2 different via c7 epia motherboards (mini
itx boards with single chip chipset with unichrome integrated graphics) machines.
They would freeze (hard) pretty much at random while working in programs like
openoffice or firefox. He end up writing a script which would repeatedly start
firefox and thunderbird, wait for the cpu load to become zero, kill them again,
etc. This killed the system reproducable, usually within the hour, always
within 5 hours.
He gave one to me with the request to see if I could fix it. After many days of
experimenting (latest bios update, try various settings, verify cooling, etc),
I've found out that (on a fully up2date Fedora 7 system) replacing the i686
kernel with the i586 one and the glibc with the i386 (and openssl, but that
wasn't used afaik) will make the system stable.
So appearantly the via c7 isn't all that i686 compatible as via claims, I
suspect that there may be a problem with certain i686 specific synchronisation
instructions, but that is just a hunge.
This leads to the conclusion, that anacondo should perhaps be modified to mark
these systems as i586 and thus choose a i586 kernel and a i386 glibc when
installing on them. But before filing a but I first wanted to discuss this here.
Regards,
Hans
16 years
gcc in f8/x86 using more stack than in rhel5?
by Eric Sandeen
I did a quick experiment, and it seems that by and large, gcc in f8 (gcc
version 4.1.2 20070821 (Red Hat 4.1.2-19)) is using slightly more stack
when building a kernel than is gcc on rhel5 (gcc version 4.1.1 20070105
(Red Hat 4.1.1-52)) There are a few functions using less, too, though.
After much checkstack output frobbing:
function [module] : old : new : delta
--------------------------------------
acpi_add_single_object [vmlinux]: 156 160 : 4
acpi_cpufreq_cpu_init [acpi-cpufreq]: 136 140 : 4
adi_connect [adi]: 144 148 : 4
aes_decrypt [aes]: 140 144 : 4
ahc_pci_config [aic7xxx]: 152 148 : -4
ata_do_eh [libata]: 292 304 : 12
aty128_probe [aty128fb]: 272 276 : 4
balance_internal [reiserfs]: 148 160 : 12
bond_arp_send_all [bonding]: 132 136 : 4
capidtmf_recv_block [divacapi]: 188 192 : 4
cciss_update_non_disk_devices [cciss]: 548 552 : 4
cfb_copyarea [vmlinux]: 148 144 : -4
check_balance [reiserfs]: 268 272 : 4
copy_to_user_tmpl [vmlinux]: 400 404 : 4
ctnetlink_new_expect [nf_conntrack_netlink]: 232 236 : 4
decode_rs16 [reed_solomon]: 220 224 : 4
diNewExt [jfs]: 112 108 : -4
diva_add_card [divacapi]: 144 156 : 12
do_balance [reiserfs]: 308 320 : 12
do_cciss_request [cciss]: 544 548 : 4
do_con_write [vmlinux]: 160 156 : -4
do_tx [eni]: 120 124 : 4
ea_dealloc_unstuffed [gfs2]: 116 120 : 4
ehci_urb_enqueue [ehci-hcd]: 196 212 : 16
ext4_expand_extra_isize_ea [ext4dev]: 128 132 : 4
ext4_ext_insert_extent [ext4dev]: 144 148 : 4
ext4_ext_remove_space [ext4dev]: 120 124 : 4
facility_req [divacapi]: 396 392 : -4
__fat_readdir [fat]: 252 256 : 4
fat_search_long [fat]: 408 412 : 4
fetch_frame [cpia]: 184 196 : 12
ftdi_elan_status_work [ftdi-elan]: 252 248 : -4
gdth_detect [gdth]: 440 436 : -4
get_far_parent [reiserfs]: 140 152 : 12
hfcpci_interrupt [hisax]: 356 360 : 4
hptiop_probe [hptiop]: 152 156 : 4
huft_build [vmlinux]: 152 144 : -8
ieee80211_master_start_xmit [mac80211]: 176 180 : 4
ieee80211_sta_work [mac80211]: 464 476 : 12
i_ipmi_request [ipmi_msghandler]: 108 100 : -8
inftl_scan_bbt [diskonchip]: 196 200 : 4
ip_route_input [vmlinux]: 196 192 : -4
ip_setsockopt [vmlinux]: 448 452 : 4
isdn_tty_write [isdn]: 160 164 : 4
ivtv_process_vbi_data [ivtv]: 116 120 : 4
jfs_readdir [jfs]: 348 340 : -8
key_schedule [cast5]: 608 596 : -12
matroxfb_dh_set_par [matroxfb_crtc2]: 116 120 : 4
matroxfb_ioctl [matroxfb_base]: 136 140 : 4
mmc_blk_issue_rq [mmc_block]: 360 356 : -4
module_verify_signature [vmlinux]: 124 120 : -4
myri10ge_xmit [myri10ge]: 112 116 : 4
nv_tx_timeout [forcedeth]: 156 144 : -12
ocfs2_write_cluster_by_desc [ocfs2]: 112 108 : -4
os_scsi_tape_open [osst]: 180 184 : 4
paging32_page_fault [kvm]: 116 108 : -8
parse_audio_unit [snd-usb-audio]: 132 144 : 12
patch_cmi9880 [snd-hda-intel]: 108 124 : 16
pbus_size_mem [vmlinux]: 124 128 : 4
pkt_open [pktcdvd]: 556 560 : 4
prism2_plx_probe [hostap_plx]: 116 136 : 20
qla1280_nvram_config [qla1280]: 128 160 : 32
r300_do_cp_cmdbuf [radeon]: 580 572 : -8
radeon_check_modes [radeonfb]: 204 212 : 8
radeon_get_pllinfo [radeonfb]: 176 192 : 16
s2io_add_isr [s2io]: 176 184 : 8
savage_dispatch_draw [savage]: 304 308 : 4
sd_revalidate_disk [sd_mod]: 156 116 : -40
search_by_key [reiserfs]: 256 272 : 16
send_s870 [atp870u]: 100 104 : 4
service_interrupt [atmel]: 188 192 : 4
_snd_emu10k1_audigy_init_efx [snd-emu10k1]: 160 164 : 4
snd_emu10k1_init_efx [snd-emu10k1]: 136 172 : 36
snd_intel8x0_probe [snd-intel8x0]: 156 148 : -8
snd_mixart_hw_params [snd-mixart]: 268 272 : 4
snd_pcm_common_ioctl1 [snd-pcm]: 272 276 : 4
snd_pcm_hw_refine [snd-pcm]: 160 168 : 8
snd_pcm_oss_change_params [snd-pcm-oss]: 168 176 : 8
snd_usb_create_midi_interface [snd-usb-lib]: 112 116 : 4
sr_probe [sr_mod]: 140 144 : 4
start_preview [saa7134]: 212 232 : 20
st_ioctl [st]: 128 144 : 16
stv680_newframe [stv680]: 176 192 : 16
svcauth_gss_accept [auth_rpcgss]: 216 208 : -8
sys_copyarea [syscopyarea]: 144 140 : -4
sys_init_module [vmlinux]: 232 236 : 4
tcp_sendmsg [vmlinux]: 128 120 : -8
tcp_v4_do_rcv [vmlinux]: 104 108 : 4
tulip_init_one [tulip]: 136 140 : 4
tveeprom_hauppauge_analog [tveeprom]: 156 164 : 8
txCommit [jfs]: 168 180 : 12
udf_get_block [udf]: 412 416 : 4
udf_get_filename [udf]: 584 580 : -4
write_filehandle [nfsd]: 208 204 : -4
xfs_alloc_delrec [xfs]: 132 144 : 12
xfs_bmap_btalloc [xfs]: 172 180 : 8
xfs_bmbt_delrec [xfs]: 212 216 : 4
xfs_bmbt_newroot [xfs]: 132 140 : 8
xfs_da_do_buf [xfs]: 188 192 : 4
xfs_inobt_delrec [xfs]: 148 152 : 4
xfs_inobt_newroot [xfs]: 172 176 : 4
xtSearch [jfs]: 104 116 : 12
xtUpdate [jfs]: 404 424 : 20
zd1201_usbrx [zd1201]: 100 108 : 8
------------------------
Functions increased: 79
Functions decreased: 25
Net change: +432 bytes
that starts with checkstack output, so it's only checking functions
using > 100 bytes of stack, and then the above is only showing functions
with changed stack usage... but from a spot-check, smaller stack-users
are affected as well.
With 4KSTACKS on x86, I'm afraid this could add up to more problems.
Any idea what might be causing this?
Thanks,
-Eric
16 years, 1 month
how to debug my kernel
by Feng Xian
Hi,
I'm currently working on a project which needs to modify linux scheduler.
But my new kernel always gets crashed after one-day's run. There is no OOPS
message coming out when it crashed.
What should I do?
Best regards
Feng
--
Addr: 1025N, 23rd str, APT 33,
Lincoln, NE, 68503
Phone: (402)310-9826
WWW: cse.unl.edu/~fxian
16 years, 1 month
sparc64 needs an entirely untouched, unstripped kernel
by Tom Callaway
In testing, I've found that sparc64 needs an entirely untouched,
unstripped kernel in order to netboot. The kernels which have gone
through the debuginfo process did not netboot properly, but an untouched
copy of the kernel made right after it is built work fine.
This is a variant of the spec code we've been using in Aurora for a
while, it enables a with-unstripped option, and only enables it for
sparc64. If enabled, it makes a copy, calls it foo-UNSTRIPPED, and
includes it in the %files macro.
If this is ok, let me know, and I'll commit it in rawhide. If there is a
better way to be doing this, also let me know. :)
~spot
16 years, 1 month
[Fwd: Testing the Current Upstream Kernel]
by Thorsten Leemhuis
Hi,
did you guys see this discussion on LKML? Should we build the vanilla
kernel (¹) by default during our build process and put it in some
special repo maybe (or even in the main repo?)?
CU
knurd
(¹) -- btw: Jarod, thx for making it easy to build one
16 years, 1 month