kernel August 2007

kernel@lists.fedoraproject.org

35 participants
27 discussions

bugzilla triage.
by Dave Jones 16 Sep '07

16 Sep '07

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

2 1

-vanilla builds.
by Dave Jones 31 Aug '07

31 Aug '07

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

5 6

[RFC PATCH] lirc IR receiver drivers
by Jarod Wilson 28 Aug '07

28 Aug '07

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

3 7

The NFS "nosharecache" patch in F7 is broken
by Chuck Ebbert 27 Aug '07

27 Aug '07

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?

4 9

Need to use i586 kernel and i386 glibc for via c7 epia system
by Hans de Goede 27 Aug '07

27 Aug '07

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

2 2

gcc in f8/x86 using more stack than in rhel5?
by Eric Sandeen 24 Aug '07

24 Aug '07

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

2 2

how to debug my kernel
by Feng Xian 23 Aug '07

23 Aug '07

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

3 2

sparc64 needs an entirely untouched, unstripped kernel
by Tom Callaway 18 Aug '07

18 Aug '07

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

3 5

[Fwd: Testing the Current Upstream Kernel]
by Thorsten Leemhuis 17 Aug '07

17 Aug '07

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

5 10

[PATCH] fix development --with vanilla build
by Matthew Kent 16 Aug '07

16 Aug '07

Tiny patch to fix vanilla builds trying to make a missing target. -- Matthew Kent <mkent(a)magoazul.com> http://magoazul.com

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel August 2007