Re: earlier ctrl-alt-del
On Thu, Feb 14, 2008 at 2:10 AM, Nick Levinson <[EMAIL PROTECTED]> wrote: > Suggestion: ctrl-alt-del should be a working command > earlier in the bootup process, so that reboots won't > take so long because we have to wait. For example, I > sometimes have to change something in BIOS and then > must reboot, which means I have to go almost to the > login stage before I can warm-reboot. > sysrq are working early in the boot process (sysrq s/u/b): http://lxr.linux.no/linux/Documentation/sysrq.txt regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: earlier ctrl-alt-del
On Thu, Feb 14, 2008 at 2:10 AM, Nick Levinson [EMAIL PROTECTED] wrote: Suggestion: ctrl-alt-del should be a working command earlier in the bootup process, so that reboots won't take so long because we have to wait. For example, I sometimes have to change something in BIOS and then must reboot, which means I have to go almost to the login stage before I can warm-reboot. sysrq are working early in the boot process (sysrq s/u/b): http://lxr.linux.no/linux/Documentation/sysrq.txt regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Nov 13, 2007 3:08 PM, Mark Lord <[EMAIL PROTECTED]> wrote: > > Ingo Molnar wrote: > .. > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. > Btw, I used to test every -mm kernel. But since I've switched distros (gentoo->ubuntu) and I have less time, I feel it's harder to test -rc or -mm kernels (I know this isn't a lkml problem but more a distro problem, but I would love having an ubuntu blessed repo with current dev kernel for the latest stable ubuntu release). For debugging, maybe it's time someone does an amazon ec2+s3 service to automate the bisecting and create .deb/.rpm from git, I don't know how much it would cost though. regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Nov 13, 2007 3:08 PM, Mark Lord [EMAIL PROTECTED] wrote: Ingo Molnar wrote: .. This is all QA-101 that _cannot be argued against on a rational basis_, it's just that these sorts of things have been largely ignored for years, in favor of the all-too-easy open source means many eyeballs and that is our QA answer, which is a _good_ answer but by far not the most intelligent answer! Today many eyeballs is simply not good enough and nature (and other OS projects) will route us around if we dont change. .. QA-101 and many eyeballs are not at all in opposition. The latter is how we find out about bugs on uncommon hardware, and the former is what we need to track them and overall quality. A HUGE problem I have with current efforts, is that once someone reports a bug, the onus seems to be 99% on the *reporter* to find the exact line of code or commit. Ghad what a repressive method. Btw, I used to test every -mm kernel. But since I've switched distros (gentoo-ubuntu) and I have less time, I feel it's harder to test -rc or -mm kernels (I know this isn't a lkml problem but more a distro problem, but I would love having an ubuntu blessed repo with current dev kernel for the latest stable ubuntu release). For debugging, maybe it's time someone does an amazon ec2+s3 service to automate the bisecting and create .deb/.rpm from git, I don't know how much it would cost though. regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Which companies are helping developing the kernel
On 10/15/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote: > On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote: > > Hello, > > > > I posted this question at comp.linux.misc and where told this would be a > > better place therefore. I would like to do a internship in the field of the > > Linux kernel. > > Can someone tell me where to find a list of companies (don't matter in > > which country) that employ kernel developers? > perhaps this helps: http://lwn.net/Articles/247582/ regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Which companies are helping developing the kernel
On 10/15/07, Alistair John Strachan [EMAIL PROTECTED] wrote: On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote: Hello, I posted this question at comp.linux.misc and where told this would be a better place therefore. I would like to do a internship in the field of the Linux kernel. Can someone tell me where to find a list of companies (don't matter in which country) that employ kernel developers? perhaps this helps: http://lwn.net/Articles/247582/ regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: possible BUG while doing gpg --gen-key
On 8/24/07, Udo van den Heuvel <[EMAIL PROTECTED]> wrote: > Benoit Boissinot wrote: > > On 8/24/07, Udo van den Heuvel <[EMAIL PROTECTED]> wrote: > >> While doing gpg --gen-key I can reproduce quite well some sort of > >> crash/bug/etc: > >> # gpg --gen-key > > > > [snip] > > > > iirg gpg-keygen uses a lot of cpu time during that phase, you probably > > should verify your ram and cpu. This kind of problem is often due to > > faulty hardware. > > The box runs stable for days on end. > Only when running gpg --gen-key I get this issue. > Other gpg operations, run by a user, are without issue. > There is 512MB of RAM and the hardware is `refreshed` regularly when an > interesting VIA board comes out. Case stays closed otherwise. I am ESD > certified. (or how to put that in the english language) > memtest86 shows no problems. Kernel compiles etc run without issue. > F7 upgraded installation. Updated regularly. gnupg rpm is Red Hat-stock. > My own compiles of gnupg show the same error. > > So what is next? > Sorry, I'll let the gurus speak then ;) regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: possible BUG while doing gpg --gen-key
On 8/24/07, Udo van den Heuvel <[EMAIL PROTECTED]> wrote: > While doing gpg --gen-key I can reproduce quite well some sort of > crash/bug/etc: > # gpg --gen-key [snip] > We need to generate a lot of random bytes. It is a good idea to perform > some other action (type on the keyboard, move the mouse, utilize the > disks) during the prime generation; this gives the random number > generator a better chance to gain enough entropy. > [snip] > Segmentation fault > (...) > Call Trace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_stack_log_lvl+0x9d/0xa5 > [] show_registers+0x1cd/0x2e3 > [] die+0xfe/0x200 > [] do_page_fault+0x43c/0x511 > [] error_code+0x6a/0x70 iirg gpg-keygen uses a lot of cpu time during that phase, you probably should verify your ram and cpu. This kind of problem is often due to faulty hardware. regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: possible BUG while doing gpg --gen-key
On 8/24/07, Udo van den Heuvel [EMAIL PROTECTED] wrote: While doing gpg --gen-key I can reproduce quite well some sort of crash/bug/etc: # gpg --gen-key [snip] We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. [snip] Segmentation fault (...) Call Trace: [c0103b75] show_trace_log_lvl+0x1a/0x2f [c0103c27] show_stack_log_lvl+0x9d/0xa5 [c0103dfc] show_registers+0x1cd/0x2e3 [c0104010] die+0xfe/0x200 [c010fb77] do_page_fault+0x43c/0x511 [c030220a] error_code+0x6a/0x70 iirg gpg-keygen uses a lot of cpu time during that phase, you probably should verify your ram and cpu. This kind of problem is often due to faulty hardware. regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: possible BUG while doing gpg --gen-key
On 8/24/07, Udo van den Heuvel [EMAIL PROTECTED] wrote: Benoit Boissinot wrote: On 8/24/07, Udo van den Heuvel [EMAIL PROTECTED] wrote: While doing gpg --gen-key I can reproduce quite well some sort of crash/bug/etc: # gpg --gen-key [snip] iirg gpg-keygen uses a lot of cpu time during that phase, you probably should verify your ram and cpu. This kind of problem is often due to faulty hardware. The box runs stable for days on end. Only when running gpg --gen-key I get this issue. Other gpg operations, run by a user, are without issue. There is 512MB of RAM and the hardware is `refreshed` regularly when an interesting VIA board comes out. Case stays closed otherwise. I am ESD certified. (or how to put that in the english language) memtest86 shows no problems. Kernel compiles etc run without issue. F7 upgraded installation. Updated regularly. gnupg rpm is Red Hat-stock. My own compiles of gnupg show the same error. So what is next? Sorry, I'll let the gurus speak then ;) regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel / Fliesystem Error
On 8/9/07, Chris Holvenstot <[EMAIL PROTECTED]> wrote: > > Chris Snook wrote: > > > >The problem here is that your clock is wrong either at mount (boot) > >time or unmount (shutdown) time. There's nothing wrong with ext3, > >except that it happens to be noticing this condition. > > 1. This happens even when the system is rebooted via the shutdown -r > command - not much time for my fat fingers to get in there and dork up > the system clock. > > 2. As I stated in the original note, this does NOT happen with kernel > 2.6.22.1 - so far I have only seen it with the 2.6.23-rc1, rc2, and > rc2-git1 kernels. > But very likely time keeping was broken between .22 and .23-rc. Probably not ext3. regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel / Fliesystem Error
On 8/9/07, Chris Holvenstot [EMAIL PROTECTED] wrote: Chris Snook wrote: The problem here is that your clock is wrong either at mount (boot) time or unmount (shutdown) time. There's nothing wrong with ext3, except that it happens to be noticing this condition. 1. This happens even when the system is rebooted via the shutdown -r command - not much time for my fat fingers to get in there and dork up the system clock. 2. As I stated in the original note, this does NOT happen with kernel 2.6.22.1 - so far I have only seen it with the 2.6.23-rc1, rc2, and rc2-git1 kernels. But very likely time keeping was broken between .22 and .23-rc. Probably not ext3. regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On 5/26/07, Michael Buesch <[EMAIL PROTECTED]> wrote: On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > Yes, sure! But the help text is very unlucky and humble, and it is not clear > enough in the sense of being distinctive enough, just clear and > comprehensive. Why don't you simply submit a patch to change the helptext then? Is that ok ? Discourage people from deselecting B44_PCI Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 +++ kernel/drivers/net/Kconfig 2007-05-26 20:38:15.0 +0200 @@ -1449,7 +1449,7 @@ help Support for b44 PCI devices. - Say Y + Unless you know what you are doing, say Y here. config FORCEDETH tristate "nForce Ethernet support" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On 5/26/07, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: Yes, sure! But the help text is very unlucky and humble, and it is not clear enough in the sense of being distinctive enough, just clear and comprehensive. Why don't you simply submit a patch to change the helptext then? Is that ok ? Discourage people from deselecting B44_PCI Signed-off-by: Benoit Boissinot [EMAIL PROTECTED] --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 +++ kernel/drivers/net/Kconfig 2007-05-26 20:38:15.0 +0200 @@ -1449,7 +1449,7 @@ help Support for b44 PCI devices. - Say Y + Unless you know what you are doing, say Y here. config FORCEDETH tristate nForce Ethernet support - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.9 won't compile
On 4/6/07, Pedro Mullor Jiménez <[EMAIL PROTECTED]> wrote: Dear all, I downloaded version 2.6.9 of the kernel from kernel.org I went throught menuconfig, importing the configuration of my current 2.6.15-28-686. I then tried to compile it but the compilation exits with an error (below). I also tried to do make mrproper, got rid of the .config file, made menuconfig again without importing anything, and when compiling it failed again. The reason for me to use this kernel is because I have a VIA VT82C 693A/598/686 chipset and I suffer from perf problems (which google says only happen since 2.6.10). Might I request to be personally CC'ed in the answers/comments posted in response to this post ? I don't think 2.6.9 was gcc-4.x compatible, what version of gcc are you using ? regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.9 won't compile
On 4/6/07, Pedro Mullor Jiménez [EMAIL PROTECTED] wrote: Dear all, I downloaded version 2.6.9 of the kernel from kernel.org I went throught menuconfig, importing the configuration of my current 2.6.15-28-686. I then tried to compile it but the compilation exits with an error (below). I also tried to do make mrproper, got rid of the .config file, made menuconfig again without importing anything, and when compiling it failed again. The reason for me to use this kernel is because I have a VIA VT82C 693A/598/686 chipset and I suffer from perf problems (which google says only happen since 2.6.10). Might I request to be personally CC'ed in the answers/comments posted in response to this post ? I don't think 2.6.9 was gcc-4.x compatible, what version of gcc are you using ? regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a bug in AS scheduler?
On 2/28/07, Jens Axboe <[EMAIL PROTECTED]> wrote: On Tue, Feb 27 2007, Xiaoning Ding wrote: > Hi, > > I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c). > In function as_close_req, variable delay is in millisecond, while > ad->antic_expire is in jiffies. Doesn't the comparison of delay and > ad->antic_expire make any problem? > The related source code is quoted blow: > > if (ad->antic_status == ANTIC_OFF || !ad->ioc_finished) > delay = 0; > else > delay = ((jiffies - ad->antic_start) * 1000) / HZ; antic_start is in jiffies, the difference is here multiplied by 1000 and divided by HZ to turn it into msecs. so delay is in msecs. I am pretty sure Xiaoning was talking about antic_expire, particularly this comparison: else if (delay <= 20 && delay <= ad->antic_expire) regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a bug in AS scheduler?
On 2/28/07, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Feb 27 2007, Xiaoning Ding wrote: Hi, I am reading the source code AS scheduler in 2.6.18(as-ioscheduler.c). In function as_close_req, variable delay is in millisecond, while ad-antic_expire is in jiffies. Doesn't the comparison of delay and ad-antic_expire make any problem? The related source code is quoted blow: if (ad-antic_status == ANTIC_OFF || !ad-ioc_finished) delay = 0; else delay = ((jiffies - ad-antic_start) * 1000) / HZ; antic_start is in jiffies, the difference is here multiplied by 1000 and divided by HZ to turn it into msecs. so delay is in msecs. I am pretty sure Xiaoning was talking about antic_expire, particularly this comparison: else if (delay = 20 delay = ad-antic_expire) regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no swap!
On 2/14/07, Thibaud Hulin <[EMAIL PROTECTED]> wrote: Hi ! distro related: check https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637 and all the duplicates After compiling the kernel, I discover that my computer don't use the swap. So, I try a cat .config |grep SW, and I got : CONFIG_SWAP=y # CONFIG_X86_VISWS is not set CONFIG_X86_BSWAP=y CONFIG_SUSPEND2_SWAP=y CONFIG_SUSPEND2_REPLACE_SWSUSP=y # CONFIG_AGP_SWORKS is not set CONFIG_USB_AUERSWALD=m This is my fstab : # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 # /dev/hda1 -- converted during upgrade to edgy UUID=c0808eb9-790a-4a20-a3a2-26a4204d0fb2 / ext3 defaults,errors=remount-ro 0 1 # /dev/hda5 -- converted during upgrade to edgy UUID=dfcca30e-3b78-4110-b578-9b8835ecf062 none swap sw 0 0 #/dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 Is it a problem of LVM or RAID ? I don't understand that very well... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no swap!
On 2/14/07, Thibaud Hulin [EMAIL PROTECTED] wrote: Hi ! distro related: check https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637 and all the duplicates After compiling the kernel, I discover that my computer don't use the swap. So, I try a cat .config |grep SW, and I got : CONFIG_SWAP=y # CONFIG_X86_VISWS is not set CONFIG_X86_BSWAP=y CONFIG_SUSPEND2_SWAP=y CONFIG_SUSPEND2_REPLACE_SWSUSP=y # CONFIG_AGP_SWORKS is not set CONFIG_USB_AUERSWALD=m This is my fstab : # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 # /dev/hda1 -- converted during upgrade to edgy UUID=c0808eb9-790a-4a20-a3a2-26a4204d0fb2 / ext3 defaults,errors=remount-ro 0 1 # /dev/hda5 -- converted during upgrade to edgy UUID=dfcca30e-3b78-4110-b578-9b8835ecf062 none swap sw 0 0 #/dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 Is it a problem of LVM or RAID ? I don't understand that very well... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20/2.6.20-rc7 : ethX renumbered
On 2/11/07, Paul Rolland <[EMAIL PROTECTED]> wrote: Hello, I'm facing something quite strange... When booting one of these kernels (it's a new machine, I've not been running older kernels), the boot message says : ACPI: PCI Interrupt :04:00.0[A] -> GSI 19 (level, low) -> IRQ 19 sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2 sky2 eth0: addr 00:18:f3:e0:5d:d4 ACPI: PCI Interrupt :03:00.0[A] -> GSI 16 (level, low) -> IRQ 16 sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2 sky2 eth1: addr 00:18:f3:e0:36:fd So, I'm expecting two interfaces : eth0 and eth1 Unfortunately, at the end of the boot process, I can find eth1 and eth2, something/somewhat/someone has renumbered them ; usually distro enable persistent interface naming with udev, check /etc/iftab and see if you have something like /etc/udev/something-iftab.rules regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20/2.6.20-rc7 : ethX renumbered
On 2/11/07, Paul Rolland [EMAIL PROTECTED] wrote: Hello, I'm facing something quite strange... When booting one of these kernels (it's a new machine, I've not been running older kernels), the boot message says : ACPI: PCI Interrupt :04:00.0[A] - GSI 19 (level, low) - IRQ 19 sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2 sky2 eth0: addr 00:18:f3:e0:5d:d4 ACPI: PCI Interrupt :03:00.0[A] - GSI 16 (level, low) - IRQ 16 sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2 sky2 eth1: addr 00:18:f3:e0:36:fd So, I'm expecting two interfaces : eth0 and eth1 Unfortunately, at the end of the boot process, I can find eth1 and eth2, something/somewhat/someone has renumbered them ; usually distro enable persistent interface naming with udev, check /etc/iftab and see if you have something like /etc/udev/something-iftab.rules regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.19-rc6-mm2] Lost files on ext3 after suspend
Ok, since it is the second time it happened I decided to report it. Last week I lost some files in my home directory (at least .gnome .firefox .bashrc .Xauthority), I think it was after a suspend. Yesterday exactly the same thing happened (same kernel 2.6.19-rc6-mm2, I haven't upgraded because I feared data loss on ext3 with newer kernel as some of them were reported). I'm using the ata_piix driver (from dmesg): ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2: port disabled. ignoring. scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK6026GA PA20 PQ: 0 ANSI: 5 SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: Attached scsi disk sda with ext3 (no fancy options). I had no errors with fsck -f or badblocks. regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.19-rc6-mm2] Lost files on ext3 after suspend
Ok, since it is the second time it happened I decided to report it. Last week I lost some files in my home directory (at least .gnome .firefox .bashrc .Xauthority), I think it was after a suspend. Yesterday exactly the same thing happened (same kernel 2.6.19-rc6-mm2, I haven't upgraded because I feared data loss on ext3 with newer kernel as some of them were reported). I'm using the ata_piix driver (from dmesg): ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0x1810 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15 scsi0 : ata_piix ata1.00: ATA-6, max UDMA/100, 117210240 sectors: LBA ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2: port disabled. ignoring. scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK6026GA PA20 PQ: 0 ANSI: 5 SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 117210240 512-byte hdwr sectors (60012 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: Attached scsi disk sda with ext3 (no fancy options). I had no errors with fsck -f or badblocks. regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
On 9/8/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
>
> git-cifs.patch
it adds a new compilation warning with gcc-4:
fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function
return type
The following patch fixes it (removes the const qualifier)
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./fs/cifs/cifsglob.h2005-09-08 14:50:34.0 +0200
+++ ./fs/cifs/cifsglob.h.new2005-09-08 15:02:50.0 +0200
@@ -331,7 +331,7 @@ CIFS_SB(struct super_block *sb)
return sb->s_fs_info;
}
-static inline const char CIFS_DIR_SEP(const struct cifs_sb_info *cifs_sb)
+static inline char CIFS_DIR_SEP(const struct cifs_sb_info *cifs_sb)
{
if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_POSIX_PATHS)
return '/';
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
On 9/8/05, Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
git-cifs.patch
it adds a new compilation warning with gcc-4:
fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function
return type
The following patch fixes it (removes the const qualifier)
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
--- ./fs/cifs/cifsglob.h2005-09-08 14:50:34.0 +0200
+++ ./fs/cifs/cifsglob.h.new2005-09-08 15:02:50.0 +0200
@@ -331,7 +331,7 @@ CIFS_SB(struct super_block *sb)
return sb-s_fs_info;
}
-static inline const char CIFS_DIR_SEP(const struct cifs_sb_info *cifs_sb)
+static inline char CIFS_DIR_SEP(const struct cifs_sb_info *cifs_sb)
{
if (cifs_sb-mnt_cifs_flags CIFS_MOUNT_POSIX_PATHS)
return '/';
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote:
> This should fix it, but I'm not on a machine where I can test it. Can
> you give it a try and let me know?
>
it works ok.
But there is still at least one problem: if ops->store returns an error,
then there will be a substraction and the write will loop (i could do it
with a store wich returned EINVAL and a 22 length string).
I don't know if you can put a '\0' at buffer->page[count] if
count == PAGE_SIZE.
Moreover, i think it is more correct to add only the leading
whitespace from the count because if the ops->store doesn't read
everything it will do something weird:
For example, if we have ' 123' and ops->store read only one char,
then the function will return 7 (1 leading + 4 trailing + 1 read). For
the next call the buffer will be filled only by spaces which is
incorrect (it should be '23').
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -207,8 +208,28 @@ flush_write_buffer(struct dentry * dentr
> struct attribute * attr = to_attr(dentry);
> struct kobject * kobj = to_kobj(dentry->d_parent);
> struct sysfs_ops * ops = buffer->ops;
> + int ws_count = count;
> + char *x;
>
> - return ops->store(kobj,attr,buffer->page,count);
> + /* locate trailing white space */
> + while ((count > 0) && isspace(buffer->page[count - 1]))
> + count--;
> +
> + /* locate leading white space */
> + x = buffer->page;
> + if (count > 0) {
> + while (isspace(*x))
> + x++;
> + count -= (x - buffer->page);
> + }
> + /* terminate the string */
> + x[count] = '\0';
what if count == PAGE_SIZE ?
> + ws_count -= count;
> +
> + if (count != 0)
> + count = ops->store(kobj, attr, x, count);
> +
> + return count + ws_count;
return (count < 0) ? count : count + ws_count;
> }
>
>
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Mon, Aug 22, 2005 at 12:44:01PM -0400, Jon Smirl wrote: > On 8/22/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote: > > > This should fix it, but I'm not on a machine where I can test it. Can > > > you give it a try and let me know? > > > > > > > it works ok. > > But there is still at least one problem: if ops->store returns an error, > > then there will be a substraction and the write will loop (i could do it > > with a store wich returned EINVAL and a 22 length string). > > > > I don't know if you can put a '\0' at buffer->page[count] if > > count == PAGE_SIZE. > > > > Moreover, i think it is more correct to add only the leading > > whitespace from the count because if the ops->store doesn't read > > everything it will do something weird: > > > > For example, if we have ' 123' and ops->store read only one char, > > then the function will return 7 (1 leading + 4 trailing + 1 read). For > > the next call the buffer will be filled only by spaces which is > > incorrect (it should be '23'). > > The attached version tries to fix these issues. I am still not > somewhere where I can test, so please check it out. > Yes it works fine, thanks. Benoit Boissinot -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Mon, Aug 22, 2005 at 12:44:01PM -0400, Jon Smirl wrote: On 8/22/05, Benoit Boissinot [EMAIL PROTECTED] wrote: On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote: This should fix it, but I'm not on a machine where I can test it. Can you give it a try and let me know? it works ok. But there is still at least one problem: if ops-store returns an error, then there will be a substraction and the write will loop (i could do it with a store wich returned EINVAL and a 22 length string). I don't know if you can put a '\0' at buffer-page[count] if count == PAGE_SIZE. Moreover, i think it is more correct to add only the leading whitespace from the count because if the ops-store doesn't read everything it will do something weird: For example, if we have ' 123' and ops-store read only one char, then the function will return 7 (1 leading + 4 trailing + 1 read). For the next call the buffer will be filled only by spaces which is incorrect (it should be '23'). The attached version tries to fix these issues. I am still not somewhere where I can test, so please check it out. Yes it works fine, thanks. Benoit Boissinot -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Sun, Aug 21, 2005 at 06:34:48PM -0400, Jon Smirl wrote:
This should fix it, but I'm not on a machine where I can test it. Can
you give it a try and let me know?
it works ok.
But there is still at least one problem: if ops-store returns an error,
then there will be a substraction and the write will loop (i could do it
with a store wich returned EINVAL and a 22 length string).
I don't know if you can put a '\0' at buffer-page[count] if
count == PAGE_SIZE.
Moreover, i think it is more correct to add only the leading
whitespace from the count because if the ops-store doesn't read
everything it will do something weird:
For example, if we have ' 123' and ops-store read only one char,
then the function will return 7 (1 leading + 4 trailing + 1 read). For
the next call the buffer will be filled only by spaces which is
incorrect (it should be '23').
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -6,6 +6,7 @@
#include linux/fsnotify.h
#include linux/kobject.h
#include linux/namei.h
+#include linux/ctype.h
#include asm/uaccess.h
#include asm/semaphore.h
@@ -207,8 +208,28 @@ flush_write_buffer(struct dentry * dentr
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry-d_parent);
struct sysfs_ops * ops = buffer-ops;
+ int ws_count = count;
+ char *x;
- return ops-store(kobj,attr,buffer-page,count);
+ /* locate trailing white space */
+ while ((count 0) isspace(buffer-page[count - 1]))
+ count--;
+
+ /* locate leading white space */
+ x = buffer-page;
+ if (count 0) {
+ while (isspace(*x))
+ x++;
+ count -= (x - buffer-page);
+ }
+ /* terminate the string */
+ x[count] = '\0';
what if count == PAGE_SIZE ?
+ ws_count -= count;
+
+ if (count != 0)
+ count = ops-store(kobj, attr, x, count);
+
+ return count + ws_count;
return (count 0) ? count : count + ws_count;
}
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
- Forwarded message from Benoit Boissinot <[EMAIL PROTECTED]> - sorry, i forgot to reply all... From: Benoit Boissinot <[EMAIL PROTECTED]> To: Jon Smirl <[EMAIL PROTECTED]> Subject: Re: 2.6.13-rc6-mm1 User-Agent: Mutt/1.5.10i On Sun, Aug 21, 2005 at 06:11:57PM -0400, Jon Smirl wrote: > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote: > > > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > > [snip] > > > > > > Somewhere there is a mistake in the white space processing code of the > > > firmware driver. Before this patch we had inconsistent handling of > > > whitespace and sysfs attributes. This patch forces it to be consistent > > > and will shake out all of the places in the drivers where it is > > > handled wrong. Sysfs attributes are now stripped of leading and > > > trailing white space before being handed to the device driver. > > > > ok, i found it. If i do echo 1, it will read '1\n', will > > remove the '\n' and send '1' to ops->store. > > Then it will re-read '\n' and send '' to ops->store. > > And it will loop... > > Look at the length being passed in, isn't it set to zero for the second case? > yes, it is set to zero, but the '\n' will be stripped and stay in the buffer. Since flush_write_buffer returns 0, ppos will not be incremented and we have an endless loop. -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - End forwarded message - -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/ > > - Lots of fixes, updates and cleanups all over the place. > > - If you have the right debugging options set, this kernel will generate > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. > It is being worked on. > > > Changes since 2.6.13-rc5-mm1: > [...] > +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch > [...] it broke loading of firmware for me.(dmesg was flooded with "firmware_loading_store: unexpected value (0)") firmware.agent uses echo so there is a trailing newline. If i changes firmware.agent to uses echo -n it works correctly. Is this a bug or the correct behaviour ? regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote: > On 8/21/05, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > On 8/19/05, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/ > > > > > > - Lots of fixes, updates and cleanups all over the place. > > > > > > - If you have the right debugging options set, this kernel will generate > > > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. > > > It is being worked on. > > > > > > > > > Changes since 2.6.13-rc5-mm1: > > > [...] > > > +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch > > > [...] > > > > > > it broke loading of firmware for me.(dmesg was flooded with > > "firmware_loading_store: unexpected value (0)") > > > > firmware.agent uses echo so there is a trailing newline. If i changes > > firmware.agent to uses echo -n it works correctly. > > > > Is this a bug or the correct behaviour ? > > Somewhere there is a mistake in the white space processing code of the > firmware driver. Before this patch we had inconsistent handling of > whitespace and sysfs attributes. This patch forces it to be consistent > and will shake out all of the places in the drivers where it is > handled wrong. Sysfs attributes are now stripped of leading and > trailing white space before being handed to the device driver. ok, i found it. If i do echo 1, it will read '1\n', will remove the '\n' and send '1' to ops->store. Then it will re-read '\n' and send '' to ops->store. And it will loop... Maybe sysfs should return the old count instead of ops->store ? > > Fbdev sysfs attributes are also broken for white space handling and > need to be fixed. Overall the patch should be correct and it is the > drivers that are broken. > Regards, Benoit Boissinot -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote: On 8/21/05, Benoit Boissinot [EMAIL PROTECTED] wrote: On 8/19/05, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/ - Lots of fixes, updates and cleanups all over the place. - If you have the right debugging options set, this kernel will generate a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. It is being worked on. Changes since 2.6.13-rc5-mm1: [...] +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch [...] it broke loading of firmware for me.(dmesg was flooded with firmware_loading_store: unexpected value (0)) firmware.agent uses echo so there is a trailing newline. If i changes firmware.agent to uses echo -n it works correctly. Is this a bug or the correct behaviour ? Somewhere there is a mistake in the white space processing code of the firmware driver. Before this patch we had inconsistent handling of whitespace and sysfs attributes. This patch forces it to be consistent and will shake out all of the places in the drivers where it is handled wrong. Sysfs attributes are now stripped of leading and trailing white space before being handed to the device driver. ok, i found it. If i do echo 1, it will read '1\n', will remove the '\n' and send '1' to ops-store. Then it will re-read '\n' and send '' to ops-store. And it will loop... Maybe sysfs should return the old count instead of ops-store ? Fbdev sysfs attributes are also broken for white space handling and need to be fixed. Overall the patch should be correct and it is the drivers that are broken. Regards, Benoit Boissinot -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On 8/19/05, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/ - Lots of fixes, updates and cleanups all over the place. - If you have the right debugging options set, this kernel will generate a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. It is being worked on. Changes since 2.6.13-rc5-mm1: [...] +gregkh-driver-sysfs-strip_leading_trailing_whitespace.patch [...] it broke loading of firmware for me.(dmesg was flooded with firmware_loading_store: unexpected value (0)) firmware.agent uses echo so there is a trailing newline. If i changes firmware.agent to uses echo -n it works correctly. Is this a bug or the correct behaviour ? regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
- Forwarded message from Benoit Boissinot [EMAIL PROTECTED] - sorry, i forgot to reply all... From: Benoit Boissinot [EMAIL PROTECTED] To: Jon Smirl [EMAIL PROTECTED] Subject: Re: 2.6.13-rc6-mm1 User-Agent: Mutt/1.5.10i On Sun, Aug 21, 2005 at 06:11:57PM -0400, Jon Smirl wrote: On 8/21/05, Benoit Boissinot [EMAIL PROTECTED] wrote: On Sun, Aug 21, 2005 at 01:40:31PM -0400, Jon Smirl wrote: On 8/21/05, Benoit Boissinot [EMAIL PROTECTED] wrote: [snip] Somewhere there is a mistake in the white space processing code of the firmware driver. Before this patch we had inconsistent handling of whitespace and sysfs attributes. This patch forces it to be consistent and will shake out all of the places in the drivers where it is handled wrong. Sysfs attributes are now stripped of leading and trailing white space before being handed to the device driver. ok, i found it. If i do echo 1, it will read '1\n', will remove the '\n' and send '1' to ops-store. Then it will re-read '\n' and send '' to ops-store. And it will loop... Look at the length being passed in, isn't it set to zero for the second case? yes, it is set to zero, but the '\n' will be stripped and stay in the buffer. Since flush_write_buffer returns 0, ppos will not be incremented and we have an endless loop. -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - End forwarded message - -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Fri, Aug 19, 2005 at 05:01:05PM -0400, Ed Tomlinson wrote:
> Hi,
>
> Adding the include to dmi.h allows the compile to get past this point though I
> wonder if this is the correct place to put it? (Thanks Benoit)
>
> I now get:
>
> CC [M] net/ipv4/ipvs/ip_vs_ctl.o
> net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table'
> follows non-static declaration
> include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here
> make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1
> make[2]: *** [net/ipv4/ipvs] Error 2
> make[1]: *** [net/ipv4] Error 2
> make: *** [net] Error 2
>
> Ideas?
>
I think the following is patch needed because ipv4_table is local to
ipvs.
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./net/ipv4/ipvs/ip_vs_lblc.c2004-12-24 22:35:28.0 +0100
+++ ./net/ipv4/ipvs/ip_vs_lblc.c.new2005-08-19 23:22:09.0 +0200
@@ -131,7 +131,7 @@ static ctl_table vs_table[] = {
{ .ctl_name = 0 }
};
-static ctl_table ipv4_table[] = {
+static ctl_table ipv4_vs_table[] = {
{
.ctl_name = NET_IPV4,
.procname = "ipv4",
@@ -146,7 +146,7 @@ static ctl_table lblc_root_table[] = {
.ctl_name = CTL_NET,
.procname = "net",
.mode = 0555,
- .child = ipv4_table
+ .child = ipv4_vs_table
},
{ .ctl_name = 0 }
};
--- ./net/ipv4/ipvs/ip_vs_lblcr.c 2004-12-24 22:35:24.0 +0100
+++ ./net/ipv4/ipvs/ip_vs_lblcr.c.new 2005-08-19 23:22:25.0 +0200
@@ -320,7 +320,7 @@ static ctl_table vs_table[] = {
{ .ctl_name = 0 }
};
-static ctl_table ipv4_table[] = {
+static ctl_table ipv4_vs_table[] = {
{
.ctl_name = NET_IPV4,
.procname = "ipv4",
@@ -335,7 +335,7 @@ static ctl_table lblcr_root_table[] = {
.ctl_name = CTL_NET,
.procname = "net",
.mode = 0555,
- .child = ipv4_table
+ .child = ipv4_vs_table
},
{ .ctl_name = 0 }
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On 8/19/05, Ed Tomlinson <[EMAIL PROTECTED]> wrote: > On Friday 19 August 2005 07:33, Andrew Morton wrote: > > - Lots of fixes, updates and cleanups all over the place. > > > > - If you have the right debugging options set, this kernel will generate > > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. > > It is being worked on. > > > > > > Changes since 2.6.13-rc5-mm1: > > > > Hi, > > It does not compile here: > > CC drivers/acpi/sleep/main.o > In file included from drivers/acpi/sleep/main.c:15: > include/linux/dmi.h:55: error: field 'list' has incomplete type > make[3]: *** [drivers/acpi/sleep/main.o] Error 1 > make[2]: *** [drivers/acpi/sleep] Error 2 > make[1]: *** [drivers/acpi] Error 2 > make: *** [drivers] Error 2 > [EMAIL PROTECTED]:/usr/src/13-6-1$ > > Probably a missing include? Note that this is a non smp x86_64 build. > including in dmi.h should work regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On 8/19/05, Ed Tomlinson [EMAIL PROTECTED] wrote: On Friday 19 August 2005 07:33, Andrew Morton wrote: - Lots of fixes, updates and cleanups all over the place. - If you have the right debugging options set, this kernel will generate a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. It is being worked on. Changes since 2.6.13-rc5-mm1: Hi, It does not compile here: CC drivers/acpi/sleep/main.o In file included from drivers/acpi/sleep/main.c:15: include/linux/dmi.h:55: error: field 'list' has incomplete type make[3]: *** [drivers/acpi/sleep/main.o] Error 1 make[2]: *** [drivers/acpi/sleep] Error 2 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2 [EMAIL PROTECTED]:/usr/src/13-6-1$ Probably a missing include? Note that this is a non smp x86_64 build. including linux/list.h in dmi.h should work regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Fri, Aug 19, 2005 at 05:01:05PM -0400, Ed Tomlinson wrote:
Hi,
Adding the include to dmi.h allows the compile to get past this point though I
wonder if this is the correct place to put it? (Thanks Benoit)
I now get:
CC [M] net/ipv4/ipvs/ip_vs_ctl.o
net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table'
follows non-static declaration
include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here
make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1
make[2]: *** [net/ipv4/ipvs] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2
Ideas?
I think the following is patch needed because ipv4_table is local to
ipvs.
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
--- ./net/ipv4/ipvs/ip_vs_lblc.c2004-12-24 22:35:28.0 +0100
+++ ./net/ipv4/ipvs/ip_vs_lblc.c.new2005-08-19 23:22:09.0 +0200
@@ -131,7 +131,7 @@ static ctl_table vs_table[] = {
{ .ctl_name = 0 }
};
-static ctl_table ipv4_table[] = {
+static ctl_table ipv4_vs_table[] = {
{
.ctl_name = NET_IPV4,
.procname = ipv4,
@@ -146,7 +146,7 @@ static ctl_table lblc_root_table[] = {
.ctl_name = CTL_NET,
.procname = net,
.mode = 0555,
- .child = ipv4_table
+ .child = ipv4_vs_table
},
{ .ctl_name = 0 }
};
--- ./net/ipv4/ipvs/ip_vs_lblcr.c 2004-12-24 22:35:24.0 +0100
+++ ./net/ipv4/ipvs/ip_vs_lblcr.c.new 2005-08-19 23:22:25.0 +0200
@@ -320,7 +320,7 @@ static ctl_table vs_table[] = {
{ .ctl_name = 0 }
};
-static ctl_table ipv4_table[] = {
+static ctl_table ipv4_vs_table[] = {
{
.ctl_name = NET_IPV4,
.procname = ipv4,
@@ -335,7 +335,7 @@ static ctl_table lblcr_root_table[] = {
.ctl_name = CTL_NET,
.procname = net,
.mode = 0555,
- .child = ipv4_table
+ .child = ipv4_vs_table
},
{ .ctl_name = 0 }
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix invalid kmalloc flags (GFP_DMA alone)
On Fri, Aug 05, 2005 at 07:05:00PM -0700, Andrew Morton wrote:
> Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Aug 05, 2005 at 05:36:29PM -0700, Andrew Morton wrote:
> > > No, GFP_DMA should work OK. Except GFP_DMA doesn't have __GFP_VALID set.
> > > It's strange that this didn't get noticed earlier.
> > >
> > > Ben, was there a reason for not giving GFP_DMA the treatment?
> >
> > Not really. Traditionally GFP_DMA was always mixed in with GFP_KERNEL or
> > GFP_ATOMIC. It seems that GFP_DMA wasn't in the hunk of defines that all
> > the other kernel flags were in, so if GFP_DMA is really valid all by
> > itself,
> > adding in the __GFP_VALID should be okay.
> >
>
> OK, it seems that pretty much all callers do remember to add GFP_KERNEL so
> I guess we can treat this as a bug-which-ben's-patch-found and merge
> Benoit's fix.
The following patch should catch all the other calls with GFP_DMA and
without either GFP_KERNEL or GFP_ATOMIC.
I didn't included the previous patch (for arch/s390/mm/extmem.c).
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
diff -urp -X other/Documentation/dontdiff truc/arch/s390/appldata/appldata_os.c
other/arch/s390/appldata/appldata_os.c
--- truc/arch/s390/appldata/appldata_os.c 2005-08-06 02:13:50.0
+0200
+++ other/arch/s390/appldata/appldata_os.c 2005-08-06 09:26:53.0
+0200
@@ -194,7 +194,7 @@ static int __init appldata_os_init(void)
P_DEBUG("sizeof(os) = %i, sizeof(os_cpu) = %lu\n", size,
sizeof(struct appldata_os_per_cpu));
- appldata_os_data = kmalloc(size, GFP_DMA);
+ appldata_os_data = kmalloc(size, GFP_DMA|GFP_KERNEL);
if (appldata_os_data == NULL) {
P_ERROR("No memory for %s!\n", ops.name);
rc = -ENOMEM;
diff -urp -X other/Documentation/dontdiff truc/drivers/net/b44.c
other/drivers/net/b44.c
--- truc/drivers/net/b44.c 2005-08-06 02:14:41.0 +0200
+++ other/drivers/net/b44.c 2005-08-06 09:40:10.0 +0200
@@ -632,7 +632,7 @@ static int b44_alloc_rx_skb(struct b44 *
/* Sigh... */
pci_unmap_single(bp->pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
- skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_DMA);
+ skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_ATOMIC|GFP_DMA);
if (skb == NULL)
return -ENOMEM;
mapping = pci_map_single(bp->pdev, skb->data,
diff -urp -X other/Documentation/dontdiff
truc/drivers/net/wireless/hostap/hostap_hw.c
other/drivers/net/wireless/hostap/hostap_hw.c
--- truc/drivers/net/wireless/hostap/hostap_hw.c2005-08-06
02:14:41.0 +0200
+++ other/drivers/net/wireless/hostap/hostap_hw.c 2005-08-06
09:58:22.0 +0200
@@ -3308,7 +3308,7 @@ prism2_init_local_data(struct prism2_hel
#if defined(PRISM2_PCI) && defined(PRISM2_BUS_MASTER)
local->bus_m0_buf = (u8 *) kmalloc(sizeof(struct hfa384x_tx_frame) +
- PRISM2_DATA_MAXLEN, GFP_DMA);
+ PRISM2_DATA_MAXLEN,
GFP_ATOMIC|GFP_DMA);
if (local->bus_m0_buf == NULL)
goto fail;
#endif /* PRISM2_PCI and PRISM2_BUS_MASTER */
diff -urp -X other/Documentation/dontdiff truc/drivers/s390/net/claw.c
other/drivers/s390/net/claw.c
--- truc/drivers/s390/net/claw.c2005-08-06 02:14:41.0 +0200
+++ other/drivers/s390/net/claw.c 2005-08-06 10:18:19.0 +0200
@@ -2198,7 +2198,7 @@ init_ccw_bk(struct net_device *dev)
*/
if (privptr->p_buff_ccw==NULL) {
privptr->p_buff_ccw=
- (void *)__get_free_pages(__GFP_DMA,
+ (void *)__get_free_pages(__GFP_DMA|GFP_KERNEL,
(int)pages_to_order_of_mag(ccw_pages_required ));
if (privptr->p_buff_ccw==NULL) {
printk(KERN_INFO "%s: %s() "
@@ -2354,7 +2354,7 @@ init_ccw_bk(struct net_device *dev)
if (privptr->p_buff_write==NULL) {
if (privptr->p_env->write_size < PAGE_SIZE) {
privptr->p_buff_write=
- (void *)__get_free_pages(__GFP_DMA,
+ (void *)__get_free_pages(__GFP_DMA|GFP_KERNEL,
(int)pages_to_order_of_mag(claw_write_pages ));
if (privptr->p_buff_write==NULL) {
printk(KERN_INFO "%s: %s() __get_free_pages for write"
@@ -2413,7 +2413,7 @@ init_ccw_bk(struct net_device *dev)
{
privptr->p_write_free_chain=NULL;
for (i = 0; i< privptr->p_env->write_buffers ; i++) {
- p_bu
[PATCH] fix invalid kmalloc flags (GFP_DMA alone)
On Fri, Aug 05, 2005 at 07:05:00PM -0700, Andrew Morton wrote:
Benjamin LaHaise [EMAIL PROTECTED] wrote:
On Fri, Aug 05, 2005 at 05:36:29PM -0700, Andrew Morton wrote:
No, GFP_DMA should work OK. Except GFP_DMA doesn't have __GFP_VALID set.
It's strange that this didn't get noticed earlier.
Ben, was there a reason for not giving GFP_DMA the treatment?
Not really. Traditionally GFP_DMA was always mixed in with GFP_KERNEL or
GFP_ATOMIC. It seems that GFP_DMA wasn't in the hunk of defines that all
the other kernel flags were in, so if GFP_DMA is really valid all by
itself,
adding in the __GFP_VALID should be okay.
OK, it seems that pretty much all callers do remember to add GFP_KERNEL so
I guess we can treat this as a bug-which-ben's-patch-found and merge
Benoit's fix.
The following patch should catch all the other calls with GFP_DMA and
without either GFP_KERNEL or GFP_ATOMIC.
I didn't included the previous patch (for arch/s390/mm/extmem.c).
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
diff -urp -X other/Documentation/dontdiff truc/arch/s390/appldata/appldata_os.c
other/arch/s390/appldata/appldata_os.c
--- truc/arch/s390/appldata/appldata_os.c 2005-08-06 02:13:50.0
+0200
+++ other/arch/s390/appldata/appldata_os.c 2005-08-06 09:26:53.0
+0200
@@ -194,7 +194,7 @@ static int __init appldata_os_init(void)
P_DEBUG(sizeof(os) = %i, sizeof(os_cpu) = %lu\n, size,
sizeof(struct appldata_os_per_cpu));
- appldata_os_data = kmalloc(size, GFP_DMA);
+ appldata_os_data = kmalloc(size, GFP_DMA|GFP_KERNEL);
if (appldata_os_data == NULL) {
P_ERROR(No memory for %s!\n, ops.name);
rc = -ENOMEM;
diff -urp -X other/Documentation/dontdiff truc/drivers/net/b44.c
other/drivers/net/b44.c
--- truc/drivers/net/b44.c 2005-08-06 02:14:41.0 +0200
+++ other/drivers/net/b44.c 2005-08-06 09:40:10.0 +0200
@@ -632,7 +632,7 @@ static int b44_alloc_rx_skb(struct b44 *
/* Sigh... */
pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
- skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_DMA);
+ skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_ATOMIC|GFP_DMA);
if (skb == NULL)
return -ENOMEM;
mapping = pci_map_single(bp-pdev, skb-data,
diff -urp -X other/Documentation/dontdiff
truc/drivers/net/wireless/hostap/hostap_hw.c
other/drivers/net/wireless/hostap/hostap_hw.c
--- truc/drivers/net/wireless/hostap/hostap_hw.c2005-08-06
02:14:41.0 +0200
+++ other/drivers/net/wireless/hostap/hostap_hw.c 2005-08-06
09:58:22.0 +0200
@@ -3308,7 +3308,7 @@ prism2_init_local_data(struct prism2_hel
#if defined(PRISM2_PCI) defined(PRISM2_BUS_MASTER)
local-bus_m0_buf = (u8 *) kmalloc(sizeof(struct hfa384x_tx_frame) +
- PRISM2_DATA_MAXLEN, GFP_DMA);
+ PRISM2_DATA_MAXLEN,
GFP_ATOMIC|GFP_DMA);
if (local-bus_m0_buf == NULL)
goto fail;
#endif /* PRISM2_PCI and PRISM2_BUS_MASTER */
diff -urp -X other/Documentation/dontdiff truc/drivers/s390/net/claw.c
other/drivers/s390/net/claw.c
--- truc/drivers/s390/net/claw.c2005-08-06 02:14:41.0 +0200
+++ other/drivers/s390/net/claw.c 2005-08-06 10:18:19.0 +0200
@@ -2198,7 +2198,7 @@ init_ccw_bk(struct net_device *dev)
*/
if (privptr-p_buff_ccw==NULL) {
privptr-p_buff_ccw=
- (void *)__get_free_pages(__GFP_DMA,
+ (void *)__get_free_pages(__GFP_DMA|GFP_KERNEL,
(int)pages_to_order_of_mag(ccw_pages_required ));
if (privptr-p_buff_ccw==NULL) {
printk(KERN_INFO %s: %s()
@@ -2354,7 +2354,7 @@ init_ccw_bk(struct net_device *dev)
if (privptr-p_buff_write==NULL) {
if (privptr-p_env-write_size PAGE_SIZE) {
privptr-p_buff_write=
- (void *)__get_free_pages(__GFP_DMA,
+ (void *)__get_free_pages(__GFP_DMA|GFP_KERNEL,
(int)pages_to_order_of_mag(claw_write_pages ));
if (privptr-p_buff_write==NULL) {
printk(KERN_INFO %s: %s() __get_free_pages for write
@@ -2413,7 +2413,7 @@ init_ccw_bk(struct net_device *dev)
{
privptr-p_write_free_chain=NULL;
for (i = 0; i privptr-p_env-write_buffers ; i++) {
- p_buff=(void *)__get_free_pages(__GFP_DMA,
+ p_buff=(void *)__get_free_pages(__GFP_DMA|GFP_KERNEL,
(int)pages_to_order_of_mag(
privptr-p_buff_pages_perwrite) );
#ifdef IOTRACE
@@ -2489,7 +2489,7 @@ init_ccw_bk(struct
[PATCH] s390: fix invalid kmalloc flags
The following patch fixes the compilation (defconfig) of s390:
arch/s390/mm/built-in.o(.text+0x152c): In function `query_segment_type':
extmem.c: undefined reference to `__your_kmalloc_flags_are_not_valid'
arch/s390/mm/built-in.o(.text+0x19ec): In function `segment_load':
: undefined reference to `__your_kmalloc_flags_are_not_valid'
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- a/arch/s390/mm/extmem.c 2005-08-06 01:32:56.0 +0200
+++ b/arch/s390/mm/extmem.c 2005-07-31 17:46:36.0 +0200
@@ -172,8 +172,8 @@ dcss_diag_translate_rc (int vm_rc) {
static int
query_segment_type (struct dcss_segment *seg)
{
- struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA);
- struct qout64 *qout = kmalloc (sizeof(struct qout64), GFP_DMA);
+ struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA|GFP_KERNEL);
+ struct qout64 *qout = kmalloc (sizeof(struct qout64),
GFP_DMA|GFP_KERNEL);
int diag_cc, rc, i;
unsigned long dummy, vmrc;
@@ -332,7 +332,7 @@ static int
__segment_load (char *name, int do_nonshared, unsigned long *addr, unsigned
long *end)
{
struct dcss_segment *seg = kmalloc(sizeof(struct dcss_segment),
- GFP_DMA);
+ GFP_DMA|GFP_KERNEL);
int dcss_command, rc, diag_cc;
if (seg == NULL) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] implicit declaration of function `page_cache_release'
On 8/5/05, Olaf Hering <[EMAIL PROTECTED]> wrote: > On Fri, Aug 05, Benoit Boissinot wrote: > > > On 7/8/05, Olaf Hering <[EMAIL PROTECTED]> wrote: > > > > > > In file included from include2/asm/tlb.h:31, > > > from > > > linux-2.6.13-rc2-olh/arch/ppc64/kernel/pSeries_lpar.c:37: > > > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function > > > `tlb_flush_mmu': > > > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:77: warning: implicit > > > declaration of function `release_pages' > > > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function > > > `tlb_remove_page': > > > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:117: warning: implicit > > > declaration of function `page_cache_release' > > > > > This went in 2.6.13-rc3 (commit > > 542d1c88bd7f73e2e59d41b12e4a9041deea89e4), and broke sparc compilation > > because of the following circular dependency: > > asm-sparc/pgtable include linux/swap.h > > Why does it need swap.h? Do the users of pgtable.h rely on swap.h? > sparc is the only architecture to do that, it looks like it uses it for boot time linking (BTFIXUP_*). I don't know anything about sparc, so i can't fix it. (adding sparclinux@vger.kernel.org to the cc list) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] implicit declaration of function `page_cache_release'
On 7/8/05, Olaf Hering <[EMAIL PROTECTED]> wrote: > > In file included from include2/asm/tlb.h:31, > from > linux-2.6.13-rc2-olh/arch/ppc64/kernel/pSeries_lpar.c:37: > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function `tlb_flush_mmu': > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:77: warning: implicit > declaration of function `release_pages' > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function `tlb_remove_page': > linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:117: warning: implicit > declaration of function `page_cache_release' > This went in 2.6.13-rc3 (commit 542d1c88bd7f73e2e59d41b12e4a9041deea89e4), and broke sparc compilation because of the following circular dependency: asm-sparc/pgtable include linux/swap.h linux/swap.h include now linux/pagemap.h linux/pagemap.h include linux/mm.h linux/mm.h include asm/pgtable.h I haven't found a satisfactory way to resolve this, but i think the patch should be removed (it removes a warning but breaks an architecture). Regards, Benoit Boissinot > Index: linux-2.6.13-rc2-olh/include/linux/pagemap.h > === > --- linux-2.6.13-rc2-olh.orig/include/linux/swap.h > +++ linux-2.6.13-rc2-olh/include/linux/swap.h > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] implicit declaration of function `page_cache_release'
On 7/8/05, Olaf Hering [EMAIL PROTECTED] wrote: In file included from include2/asm/tlb.h:31, from linux-2.6.13-rc2-olh/arch/ppc64/kernel/pSeries_lpar.c:37: linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function `tlb_flush_mmu': linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:77: warning: implicit declaration of function `release_pages' linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function `tlb_remove_page': linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:117: warning: implicit declaration of function `page_cache_release' This went in 2.6.13-rc3 (commit 542d1c88bd7f73e2e59d41b12e4a9041deea89e4), and broke sparc compilation because of the following circular dependency: asm-sparc/pgtable include linux/swap.h linux/swap.h include now linux/pagemap.h linux/pagemap.h include linux/mm.h linux/mm.h include asm/pgtable.h I haven't found a satisfactory way to resolve this, but i think the patch should be removed (it removes a warning but breaks an architecture). Regards, Benoit Boissinot Index: linux-2.6.13-rc2-olh/include/linux/pagemap.h === --- linux-2.6.13-rc2-olh.orig/include/linux/swap.h +++ linux-2.6.13-rc2-olh/include/linux/swap.h @@ -7,6 +7,7 @@ #include linux/mmzone.h #include linux/list.h #include linux/sched.h +#include linux/pagemap.h #include asm/atomic.h #include asm/page.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] implicit declaration of function `page_cache_release'
On 8/5/05, Olaf Hering [EMAIL PROTECTED] wrote: On Fri, Aug 05, Benoit Boissinot wrote: On 7/8/05, Olaf Hering [EMAIL PROTECTED] wrote: In file included from include2/asm/tlb.h:31, from linux-2.6.13-rc2-olh/arch/ppc64/kernel/pSeries_lpar.c:37: linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function `tlb_flush_mmu': linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:77: warning: implicit declaration of function `release_pages' linux-2.6.13-rc2-olh/include/asm-generic/tlb.h: In function `tlb_remove_page': linux-2.6.13-rc2-olh/include/asm-generic/tlb.h:117: warning: implicit declaration of function `page_cache_release' This went in 2.6.13-rc3 (commit 542d1c88bd7f73e2e59d41b12e4a9041deea89e4), and broke sparc compilation because of the following circular dependency: asm-sparc/pgtable include linux/swap.h Why does it need swap.h? Do the users of pgtable.h rely on swap.h? sparc is the only architecture to do that, it looks like it uses it for boot time linking (BTFIXUP_*). I don't know anything about sparc, so i can't fix it. (adding sparclinux@vger.kernel.org to the cc list) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] s390: fix invalid kmalloc flags
The following patch fixes the compilation (defconfig) of s390:
arch/s390/mm/built-in.o(.text+0x152c): In function `query_segment_type':
extmem.c: undefined reference to `__your_kmalloc_flags_are_not_valid'
arch/s390/mm/built-in.o(.text+0x19ec): In function `segment_load':
: undefined reference to `__your_kmalloc_flags_are_not_valid'
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
--- a/arch/s390/mm/extmem.c 2005-08-06 01:32:56.0 +0200
+++ b/arch/s390/mm/extmem.c 2005-07-31 17:46:36.0 +0200
@@ -172,8 +172,8 @@ dcss_diag_translate_rc (int vm_rc) {
static int
query_segment_type (struct dcss_segment *seg)
{
- struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA);
- struct qout64 *qout = kmalloc (sizeof(struct qout64), GFP_DMA);
+ struct qin64 *qin = kmalloc (sizeof(struct qin64), GFP_DMA|GFP_KERNEL);
+ struct qout64 *qout = kmalloc (sizeof(struct qout64),
GFP_DMA|GFP_KERNEL);
int diag_cc, rc, i;
unsigned long dummy, vmrc;
@@ -332,7 +332,7 @@ static int
__segment_load (char *name, int do_nonshared, unsigned long *addr, unsigned
long *end)
{
struct dcss_segment *seg = kmalloc(sizeof(struct dcss_segment),
- GFP_DMA);
+ GFP_DMA|GFP_KERNEL);
int dcss_command, rc, diag_cc;
if (seg == NULL) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 2.6.13-rc4-mm1] mips: build fix for spinlock consolidation
The following patch is needed for mips to compile with
the spinlock consolidation patch (the include of asm-mips/atomic.h
is moved down to avoid circular dependencies).
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- linux/include/linux/spinlock.h.orig 2005-08-03 20:49:26.0 +0200
+++ linux/include/linux/spinlock.h 2005-08-03 20:54:40.0 +0200
@@ -55,7 +55,6 @@
#include
#include
-#include
/*
* Must define these before including other files, inline functions need them
@@ -207,6 +206,11 @@ extern int __lockfunc generic__raw_read_
1 : ({ local_irq_restore(flags); 0; }); \
})
+/*
+ * Pull the atomic_t declaration:
+ * (asm-mips/atomic.h needs above definitions)
+ */
+#include
/**
* atomic_dec_and_lock - lock on reaching reference count zero
* @atomic: the atomic counter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 2.6.13-rc4-mm1] mips: build fix for spinlock consolidation
The following patch is needed for mips to compile with
the spinlock consolidation patch (the include of asm-mips/atomic.h
is moved down to avoid circular dependencies).
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
--- linux/include/linux/spinlock.h.orig 2005-08-03 20:49:26.0 +0200
+++ linux/include/linux/spinlock.h 2005-08-03 20:54:40.0 +0200
@@ -55,7 +55,6 @@
#include linux/stringify.h
#include asm/system.h
-#include asm/atomic.h
/*
* Must define these before including other files, inline functions need them
@@ -207,6 +206,11 @@ extern int __lockfunc generic__raw_read_
1 : ({ local_irq_restore(flags); 0; }); \
})
+/*
+ * Pull the atomic_t declaration:
+ * (asm-mips/atomic.h needs above definitions)
+ */
+#include asm/atomic.h
/**
* atomic_dec_and_lock - lock on reaching reference count zero
* @atomic: the atomic counter
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Question: ioctl functions
It looks like (i havent checked all the tree) that every function that is registered as ioctl (or read_ioctl or fb_ioctl or ...) have an argument "unsigned long arg", then each function is using it like this: void __user *argp = (void __user *)arg; I am wondering why the argument isn't from type "void __user *". Thanks, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question: ioctl functions
It looks like (i havent checked all the tree) that every function that is registered as ioctl (or read_ioctl or fb_ioctl or ...) have an argument unsigned long arg, then each function is using it like this: void __user *argp = (void __user *)arg; I am wondering why the argument isn't from type void __user *. Thanks, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc3
On 4/21/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > Changes since 2.6.12-rc2: > > Benjamin Herrenschmidt: ... > [PATCH] ppc32: Fix cpufreq problems this depends on two patches in -mm: add-suspend-method-to-cpufreq-core.patch Add suspend method to cpufreq core add-suspend-method-to-cpufreq-core-warning-fix.patch add-suspend-method-to-cpufreq-core-warning-fix without those patches defconfig is broken on ppc32 regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] minor syctl fix in vsyscall_init
On 13 Apr 2005 20:29:13 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Wed, Apr 13, 2005 at 10:45:18AM -0700, Matt Tolentino wrote: > > > > Andi, > > > > If CONFIG_SYCTL is not enabled then the x86-64 tree > > fails to build due to use of a symbol that is not > > compiled in. Don't bother compiling in the sysctl > > register call if not building with sysctl. > > Thanks. Actually it would be better to fix up sysctl.h > to define dummy functions in this case. I thought it did > that already in fact > Yes it already does that, but kernel_root_table2 is not defined when CONFIG_SYSCTL is not set (the problem isn't with register_sysctl_table). With 2.6.12-rc3: arch/x86_64/kernel/vsyscall.c: In function `vsyscall_init': arch/x86_64/kernel/vsyscall.c:221: error: `kernel_root_table2' undeclared (first use in this function) If you prefer, i can send a patch which sets kernel_table_root2 to NULL when CONFIG_SYSCTL is not set. Or maybe there a better fix (btw is sysctl_vsyscall needed when !CONFIG_SYSCTL ?). regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/hamradio/baycom_epp.c: cleanups
On 4/20/05, Adrian Bunk <[EMAIL PROTECTED]> wrote: > The times when tricky goto's produced better codes are long gone. > > This patch should express the same in a better way, please check whether > I made any mistake. > By the way, it solves compile errors with gcc-4: a lot of drivers/net/hamradio/baycom_epp.c:690: error: jump into statement expression regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/hamradio/baycom_epp.c: cleanups
On 4/20/05, Adrian Bunk [EMAIL PROTECTED] wrote: The times when tricky goto's produced better codes are long gone. This patch should express the same in a better way, please check whether I made any mistake. By the way, it solves compile errors with gcc-4: a lot of drivers/net/hamradio/baycom_epp.c:690: error: jump into statement expression regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] minor syctl fix in vsyscall_init
On 13 Apr 2005 20:29:13 +0200, Andi Kleen [EMAIL PROTECTED] wrote: On Wed, Apr 13, 2005 at 10:45:18AM -0700, Matt Tolentino wrote: Andi, If CONFIG_SYCTL is not enabled then the x86-64 tree fails to build due to use of a symbol that is not compiled in. Don't bother compiling in the sysctl register call if not building with sysctl. Thanks. Actually it would be better to fix up sysctl.h to define dummy functions in this case. I thought it did that already in fact Yes it already does that, but kernel_root_table2 is not defined when CONFIG_SYSCTL is not set (the problem isn't with register_sysctl_table). With 2.6.12-rc3: arch/x86_64/kernel/vsyscall.c: In function `vsyscall_init': arch/x86_64/kernel/vsyscall.c:221: error: `kernel_root_table2' undeclared (first use in this function) If you prefer, i can send a patch which sets kernel_table_root2 to NULL when CONFIG_SYSCTL is not set. Or maybe there a better fix (btw is sysctl_vsyscall needed when !CONFIG_SYSCTL ?). regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc3
On 4/21/05, Linus Torvalds [EMAIL PROTECTED] wrote: Changes since 2.6.12-rc2: Benjamin Herrenschmidt: ... [PATCH] ppc32: Fix cpufreq problems this depends on two patches in -mm: add-suspend-method-to-cpufreq-core.patch Add suspend method to cpufreq core add-suspend-method-to-cpufreq-core-warning-fix.patch add-suspend-method-to-cpufreq-core-warning-fix without those patches defconfig is broken on ppc32 regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
On Apr 11, 2005 10:46 PM, Martin J. Bligh <[EMAIL PROTECTED]> wrote: > > > --On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton <[EMAIL PROTECTED]> > wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ > > > > > > - The anticipatory I/O scheduler has always been fairly useless with SCSI > > disks which perform tagged command queueing. There's a patch here from > > Jens > > which is designed to fix that up by constraining the number of requests > > which we'll leave pending in the device. > > > > The depth currently defaults to 1. Tunable in > > /sys/block/hdX/queue/iosched/queue_depth > > > > This patch hasn't been performance tested at all yet. If you think it is > > misbehaving (the usual symptom is processes stuck in D state) then please > > report it, then boot with `elevator=cfq' or `elevator=deadline' to work > > around it. > > > > - More CPU scheduler work. I hope someone is testing this stuff. > > Trying ... having some build problems that seem to be part test-harness, > part bugs. > > Meanwhile on PPC64: > > fs/cifs/misc.c: In function `cifs_convertUCSpath': > fs/cifs/misc.c:546: error: case label does not reduce to an integer constant > fs/cifs/misc.c:549: error: case label does not reduce to an integer constant > fs/cifs/misc.c:552: error: case label does not reduce to an integer constant > fs/cifs/misc.c:561: error: case label does not reduce to an integer constant > fs/cifs/misc.c:564: error: case label does not reduce to an integer constant > fs/cifs/misc.c:567: error: case label does not reduce to an integer constant > make[2]: *** [fs/cifs/misc.o] Error 1 > make[1]: *** [fs/cifs] Error 2 > make[1]: *** Waiting for unfinished jobs > > See this patch from Steve French: http://cifs.bkbits.net:8080/linux-2.5cifs/[EMAIL PROTECTED] > M. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> Changes since 2.6.12-rc2-mm2:
>
>
> bk-cifs.patch
The following patch correct an error in bk-cifs:
fs/cifs/misc.c: In function âcifs_convertUCSpathâ:
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
The utilisations of UNI_* constants show that it is should in cpu format:
for example line 542, src_char is converted in cpu_format:
src_char = le16_to_cpu(source[i]);
switch (src_char) {
...
case UNI_COLON:
...
or line 610, it is unlikely that you want to have cpu_to_le16(cpu_to_le16(x)):
target[j] = cpu_to_le16(UNI_COLON);
the following patch fixes it.
Signed-Off-By: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./fs/cifs/misc.c.orig 2005-04-11 19:18:11.0 +0200
+++ ./fs/cifs/misc.c2005-04-11 19:18:30.0 +0200
@@ -519,13 +519,13 @@ dump_smb(struct smb_hdr *smb_buf, int sm
/* Windows maps these to the user defined 16 bit Unicode range since they are
reserved symbols (along with \ and /), otherwise illegal to store
in filenames in NTFS */
-#define UNI_ASTERIK cpu_to_le16('*' + 0xF000)
-#define UNI_QUESTIONcpu_to_le16('?' + 0xF000)
-#define UNI_COLON cpu_to_le16(':' + 0xF000)
-#define UNI_GRTRTHANcpu_to_le16('>' + 0xF000)
-#define UNI_LESSTHANcpu_to_le16('<' + 0xF000)
-#define UNI_PIPEcpu_to_le16('|' + 0xF000)
-#define UNI_SLASH cpu_to_le16('\\' + 0xF000)
+#define UNI_ASTERIK ('*' + 0xF000)
+#define UNI_QUESTION('?' + 0xF000)
+#define UNI_COLON (':' + 0xF000)
+#define UNI_GRTRTHAN('>' + 0xF000)
+#define UNI_LESSTHAN('<' + 0xF000)
+#define UNI_PIPE('|' + 0xF000)
+#define UNI_SLASH ('\\' + 0xF000)
/* Convert 16 bit Unicode pathname from wire format to string in current code
page. Conversion may involve remapping up the seven characters that are
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in include/asm-m68k/setup.h
make defconfig give the following error on ppc (gcc-4):
include/asm-m68k/setup.h:365: error: array type has incomplete element
type
The following patch solves it.
Signed-Off-By: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./include/asm-m68k/setup.h.orig 2004-12-24 22:35:00.0 +0100
+++ ./include/asm-m68k/setup.h 2005-04-11 14:19:25.0 +0200
@@ -360,14 +360,14 @@ extern int m68k_is040or060;
#define COMMAND_LINE_SIZE CL_SIZE
#ifndef __ASSEMBLY__
-extern int m68k_num_memory;/* # of memory blocks found (and used)
*/
-extern int m68k_realnum_memory;/* real # of memory blocks
found */
-extern struct mem_info m68k_memory[NUM_MEMINFO];/* memory description */
-
struct mem_info {
unsigned long addr; /* physical address of memory chunk */
unsigned long size; /* length of memory chunk (in bytes) */
};
+
+extern int m68k_num_memory;/* # of memory blocks found (and used)
*/
+extern int m68k_realnum_memory;/* real # of memory blocks
found */
+extern struct mem_info m68k_memory[NUM_MEMINFO];/* memory description */
#endif
#endif /* __KERNEL__ */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in include/asm/prom.h
make defconfig give the following error on ppc (gcc-4):
arch/ppc/syslib/prom_init.c:120: error: static declaration of
âprom_display_pathsâ follows non-static declaration
include/asm/prom.h:17: error: previous declaration of âprom_display_pathsâ
was here
arch/ppc/syslib/prom_init.c:122: error: static declaration of
âprom_num_displaysâ follows non-static declaration
include/asm/prom.h:18: error: previous declaration of âprom_num_displaysâ
was here
The following patch solves it.
Signed-Off-By: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./include/asm-ppc/prom.h.orig 2005-04-11 14:49:31.0 +0200
+++ ./include/asm-ppc/prom.h2005-04-11 14:49:46.0 +0200
@@ -14,9 +14,6 @@
typedef u32 phandle;
typedef u32 ihandle;
-extern char *prom_display_paths[];
-extern unsigned int prom_num_displays;
-
struct address_range {
unsigned int space;
unsigned int address;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in arch/ppc/syslib/open_pic_defs.h
make defconfig give the following error on ppc (gcc-4):
arch/ppc/syslib/open_pic.c:36: error: static declaration of âOpenPICâ
follows non-static declaration
arch/ppc/syslib/open_pic_defs.h:175: error: previous declaration of
âOpenPICâ was here
The following patch solves it.
Signed-Off-By: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./arch/ppc/syslib/open_pic_defs.h.orig 2005-04-11 14:51:54.0
+0200
+++ ./arch/ppc/syslib/open_pic_defs.h 2005-04-11 14:52:45.0 +0200
@@ -172,9 +172,6 @@ struct OpenPIC {
OpenPIC_Processor Processor[OPENPIC_MAX_PROCESSORS];
};
-extern volatile struct OpenPIC __iomem *OpenPIC;
-
-
/*
* Current Task Priority Register
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in arch/ppc/kernel/time.c
make defconfig give the following error on ppc (gcc-4): arch/ppc/kernel/time.c:92: error: static declaration of âtime_offsetâ follows non-static declaration include/linux/timex.h:236: error: previous declaration of âtime_offsetâ was here The following patch solves it (time_offset is declared in timer.c). Signed-Off-By: Benoit Boissinot <[EMAIL PROTECTED]> --- ./arch/ppc/kernel/time.c.orig 2005-04-11 14:44:19.0 +0200 +++ ./arch/ppc/kernel/time.c2005-04-11 14:44:30.0 +0200 @@ -89,8 +89,6 @@ unsigned long tb_to_ns_scale; extern unsigned long wall_jiffies; -static long time_offset; - DEFINE_SPINLOCK(rtc_lock); EXPORT_SYMBOL(rtc_lock); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in arch/ppc/kernel/time.c
make defconfig give the following error on ppc (gcc-4): arch/ppc/kernel/time.c:92: error: static declaration of time_offset follows non-static declaration include/linux/timex.h:236: error: previous declaration of time_offset was here The following patch solves it (time_offset is declared in timer.c). Signed-Off-By: Benoit Boissinot [EMAIL PROTECTED] --- ./arch/ppc/kernel/time.c.orig 2005-04-11 14:44:19.0 +0200 +++ ./arch/ppc/kernel/time.c2005-04-11 14:44:30.0 +0200 @@ -89,8 +89,6 @@ unsigned long tb_to_ns_scale; extern unsigned long wall_jiffies; -static long time_offset; - DEFINE_SPINLOCK(rtc_lock); EXPORT_SYMBOL(rtc_lock); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in arch/ppc/syslib/open_pic_defs.h
make defconfig give the following error on ppc (gcc-4):
arch/ppc/syslib/open_pic.c:36: error: static declaration of OpenPIC
follows non-static declaration
arch/ppc/syslib/open_pic_defs.h:175: error: previous declaration of
OpenPIC was here
The following patch solves it.
Signed-Off-By: Benoit Boissinot [EMAIL PROTECTED]
--- ./arch/ppc/syslib/open_pic_defs.h.orig 2005-04-11 14:51:54.0
+0200
+++ ./arch/ppc/syslib/open_pic_defs.h 2005-04-11 14:52:45.0 +0200
@@ -172,9 +172,6 @@ struct OpenPIC {
OpenPIC_Processor Processor[OPENPIC_MAX_PROCESSORS];
};
-extern volatile struct OpenPIC __iomem *OpenPIC;
-
-
/*
* Current Task Priority Register
*/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in include/asm/prom.h
make defconfig give the following error on ppc (gcc-4):
arch/ppc/syslib/prom_init.c:120: error: static declaration of
prom_display_paths follows non-static declaration
include/asm/prom.h:17: error: previous declaration of prom_display_paths
was here
arch/ppc/syslib/prom_init.c:122: error: static declaration of
prom_num_displays follows non-static declaration
include/asm/prom.h:18: error: previous declaration of prom_num_displays
was here
The following patch solves it.
Signed-Off-By: Benoit Boissinot [EMAIL PROTECTED]
--- ./include/asm-ppc/prom.h.orig 2005-04-11 14:49:31.0 +0200
+++ ./include/asm-ppc/prom.h2005-04-11 14:49:46.0 +0200
@@ -14,9 +14,6 @@
typedef u32 phandle;
typedef u32 ihandle;
-extern char *prom_display_paths[];
-extern unsigned int prom_num_displays;
-
struct address_range {
unsigned int space;
unsigned int address;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 ppc patch] fix compilation error in include/asm-m68k/setup.h
make defconfig give the following error on ppc (gcc-4):
include/asm-m68k/setup.h:365: error: array type has incomplete element
type
The following patch solves it.
Signed-Off-By: Benoit Boissinot [EMAIL PROTECTED]
--- ./include/asm-m68k/setup.h.orig 2004-12-24 22:35:00.0 +0100
+++ ./include/asm-m68k/setup.h 2005-04-11 14:19:25.0 +0200
@@ -360,14 +360,14 @@ extern int m68k_is040or060;
#define COMMAND_LINE_SIZE CL_SIZE
#ifndef __ASSEMBLY__
-extern int m68k_num_memory;/* # of memory blocks found (and used)
*/
-extern int m68k_realnum_memory;/* real # of memory blocks
found */
-extern struct mem_info m68k_memory[NUM_MEMINFO];/* memory description */
-
struct mem_info {
unsigned long addr; /* physical address of memory chunk */
unsigned long size; /* length of memory chunk (in bytes) */
};
+
+extern int m68k_num_memory;/* # of memory blocks found (and used)
*/
+extern int m68k_realnum_memory;/* real # of memory blocks
found */
+extern struct mem_info m68k_memory[NUM_MEMINFO];/* memory description */
#endif
#endif /* __KERNEL__ */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
Changes since 2.6.12-rc2-mm2:
bk-cifs.patch
The following patch correct an error in bk-cifs:
fs/cifs/misc.c: In function cifs_convertUCSpath:
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
The utilisations of UNI_* constants show that it is should in cpu format:
for example line 542, src_char is converted in cpu_format:
src_char = le16_to_cpu(source[i]);
switch (src_char) {
...
case UNI_COLON:
...
or line 610, it is unlikely that you want to have cpu_to_le16(cpu_to_le16(x)):
target[j] = cpu_to_le16(UNI_COLON);
the following patch fixes it.
Signed-Off-By: Benoit Boissinot [EMAIL PROTECTED]
--- ./fs/cifs/misc.c.orig 2005-04-11 19:18:11.0 +0200
+++ ./fs/cifs/misc.c2005-04-11 19:18:30.0 +0200
@@ -519,13 +519,13 @@ dump_smb(struct smb_hdr *smb_buf, int sm
/* Windows maps these to the user defined 16 bit Unicode range since they are
reserved symbols (along with \ and /), otherwise illegal to store
in filenames in NTFS */
-#define UNI_ASTERIK cpu_to_le16('*' + 0xF000)
-#define UNI_QUESTIONcpu_to_le16('?' + 0xF000)
-#define UNI_COLON cpu_to_le16(':' + 0xF000)
-#define UNI_GRTRTHANcpu_to_le16('' + 0xF000)
-#define UNI_LESSTHANcpu_to_le16('' + 0xF000)
-#define UNI_PIPEcpu_to_le16('|' + 0xF000)
-#define UNI_SLASH cpu_to_le16('\\' + 0xF000)
+#define UNI_ASTERIK ('*' + 0xF000)
+#define UNI_QUESTION('?' + 0xF000)
+#define UNI_COLON (':' + 0xF000)
+#define UNI_GRTRTHAN('' + 0xF000)
+#define UNI_LESSTHAN('' + 0xF000)
+#define UNI_PIPE('|' + 0xF000)
+#define UNI_SLASH ('\\' + 0xF000)
/* Convert 16 bit Unicode pathname from wire format to string in current code
page. Conversion may involve remapping up the seven characters that are
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
On Apr 11, 2005 10:46 PM, Martin J. Bligh [EMAIL PROTECTED] wrote: --On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ - The anticipatory I/O scheduler has always been fairly useless with SCSI disks which perform tagged command queueing. There's a patch here from Jens which is designed to fix that up by constraining the number of requests which we'll leave pending in the device. The depth currently defaults to 1. Tunable in /sys/block/hdX/queue/iosched/queue_depth This patch hasn't been performance tested at all yet. If you think it is misbehaving (the usual symptom is processes stuck in D state) then please report it, then boot with `elevator=cfq' or `elevator=deadline' to work around it. - More CPU scheduler work. I hope someone is testing this stuff. Trying ... having some build problems that seem to be part test-harness, part bugs. Meanwhile on PPC64: fs/cifs/misc.c: In function `cifs_convertUCSpath': fs/cifs/misc.c:546: error: case label does not reduce to an integer constant fs/cifs/misc.c:549: error: case label does not reduce to an integer constant fs/cifs/misc.c:552: error: case label does not reduce to an integer constant fs/cifs/misc.c:561: error: case label does not reduce to an integer constant fs/cifs/misc.c:564: error: case label does not reduce to an integer constant fs/cifs/misc.c:567: error: case label does not reduce to an integer constant make[2]: *** [fs/cifs/misc.o] Error 1 make[1]: *** [fs/cifs] Error 2 make[1]: *** Waiting for unfinished jobs See this patch from Steve French: http://cifs.bkbits.net:8080/linux-2.5cifs/[EMAIL PROTECTED] M. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpuset: remove function attribute const
gcc-4 warns with
include/linux/cpuset.h:21: warning: type qualifiers ignored on function
return type
cpuset_cpus_allowed is declared with const
extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
First const should be __attribute__((const)), but the gcc manual
explains that:
"Note that a function that has pointer arguments and examines the data
pointed to must not be declared const. Likewise, a function that calls a
non-const function usually must not be const. It does not make sense for
a const function to return void."
The following patch remove const from the function declaration.
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- ./kernel/cpuset.c.orig 2005-04-09 14:14:23.0 +0200
+++ ./kernel/cpuset.c 2005-04-09 14:15:19.0 +0200
@@ -1432,7 +1432,7 @@ void cpuset_exit(struct task_struct *tsk
* tasks cpuset.
**/
-const cpumask_t cpuset_cpus_allowed(const struct task_struct *tsk)
+cpumask_t cpuset_cpus_allowed(const struct task_struct *tsk)
{
cpumask_t mask;
--- ./include/linux/cpuset.h.orig 2005-04-09 14:14:32.0 +0200
+++ ./include/linux/cpuset.h2005-04-09 14:15:30.0 +0200
@@ -18,7 +18,7 @@ extern int cpuset_init(void);
extern void cpuset_init_smp(void);
extern void cpuset_fork(struct task_struct *p);
extern void cpuset_exit(struct task_struct *p);
-extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
+extern cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
void cpuset_init_current_mems_allowed(void);
void cpuset_update_current_mems_allowed(void);
void cpuset_restrict_to_mems_allowed(unsigned long *nodes);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpuset: remove function attribute const
gcc-4 warns with
include/linux/cpuset.h:21: warning: type qualifiers ignored on function
return type
cpuset_cpus_allowed is declared with const
extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
First const should be __attribute__((const)), but the gcc manual
explains that:
Note that a function that has pointer arguments and examines the data
pointed to must not be declared const. Likewise, a function that calls a
non-const function usually must not be const. It does not make sense for
a const function to return void.
The following patch remove const from the function declaration.
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
--- ./kernel/cpuset.c.orig 2005-04-09 14:14:23.0 +0200
+++ ./kernel/cpuset.c 2005-04-09 14:15:19.0 +0200
@@ -1432,7 +1432,7 @@ void cpuset_exit(struct task_struct *tsk
* tasks cpuset.
**/
-const cpumask_t cpuset_cpus_allowed(const struct task_struct *tsk)
+cpumask_t cpuset_cpus_allowed(const struct task_struct *tsk)
{
cpumask_t mask;
--- ./include/linux/cpuset.h.orig 2005-04-09 14:14:32.0 +0200
+++ ./include/linux/cpuset.h2005-04-09 14:15:30.0 +0200
@@ -18,7 +18,7 @@ extern int cpuset_init(void);
extern void cpuset_init_smp(void);
extern void cpuset_fork(struct task_struct *p);
extern void cpuset_exit(struct task_struct *p);
-extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
+extern cpumask_t cpuset_cpus_allowed(const struct task_struct *p);
void cpuset_init_current_mems_allowed(void);
void cpuset_update_current_mems_allowed(void);
void cpuset_restrict_to_mems_allowed(unsigned long *nodes);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
const qualifiers on function returns type
Hi, there are some function who are declared this way: include/linux/cpuset.h:21 extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p); I was wondering what means const for a function returns type. K doesn't say anything about this and gcc-4 warns (warning: type qualifiers ignored on function return type) If it is a mistake, there are a few functions who should be modified. Regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
const qualifiers on function returns type
Hi, there are some function who are declared this way: include/linux/cpuset.h:21 extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p); I was wondering what means const for a function returns type. KR doesn't say anything about this and gcc-4 warns (warning: type qualifiers ignored on function return type) If it is a mistake, there are a few functions who should be modified. Regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1: Mouse stopped working
On Apr 6, 2005 8:19 AM, Joe Button <[EMAIL PROTECTED]> wrote: > Hi. > > My mouse stopped working in x.org with 2.6.12-rc1. Problem is still there in > 2.6.12-rc2. Works on 2.6.11.x with same .config (except for make oldconfig / > defaults). > > Mouse is ImPs2, xorg.conf is using /dev/input/mouse0, which seems to be > present. Board is Asus p4p800 deluxe. > Maybe you can try using /dev/input/mice, or if there is one, /dev/input/mouse1. regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1: Mouse stopped working
On Apr 6, 2005 8:19 AM, Joe Button [EMAIL PROTECTED] wrote: Hi. My mouse stopped working in x.org with 2.6.12-rc1. Problem is still there in 2.6.12-rc2. Works on 2.6.11.x with same .config (except for make oldconfig / defaults). Mouse is ImPs2, xorg.conf is using /dev/input/mouse0, which seems to be present. Board is Asus p4p800 deluxe. Maybe you can try using /dev/input/mice, or if there is one, /dev/input/mouse1. regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad does not work anymore
On Fri, Apr 01, 2005 at 07:29:15PM +0200, Benoit Boissinot wrote: > On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote: > > On Apr 1, 2005 11:43 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > > On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote: > > > > On Apr 1, 2005 11:14 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > > > > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > > > > It works, too. Which one is the best one? > > > > > > > > > > > > I tried to boot with the 2 patches applied (and the patch which solves > > > > > noresume) and now touchpad/touchpoint no longer works (with this > > > > > kernel or with an older kernel). > > > > > > > > > > > > > Should work... The patches come into play only when > > suspending/resuming. So you are saying even with an old, unpatched > > kernel ALS stopped working, right? > > > I did a suspend/resume with the patches applied. And yes it doesn't work > with an old unpatched kernel. > Detected in dmesg, but no movement. > When i booted the laptop today, the touchpad did work. I suppose it was an hardware problem or something like that. Sorry for bothering you. Thanks Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad does not work anymore
On Fri, Apr 01, 2005 at 07:29:15PM +0200, Benoit Boissinot wrote: On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote: On Apr 1, 2005 11:43 AM, Benoit Boissinot [EMAIL PROTECTED] wrote: On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote: On Apr 1, 2005 11:14 AM, Benoit Boissinot [EMAIL PROTECTED] wrote: On Mar 31, 2005 8:09 PM, Dmitry Torokhov [EMAIL PROTECTED] wrote: It works, too. Which one is the best one? I tried to boot with the 2 patches applied (and the patch which solves noresume) and now touchpad/touchpoint no longer works (with this kernel or with an older kernel). Should work... The patches come into play only when suspending/resuming. So you are saying even with an old, unpatched kernel ALS stopped working, right? I did a suspend/resume with the patches applied. And yes it doesn't work with an old unpatched kernel. Detected in dmesg, but no movement. When i booted the laptop today, the touchpad did work. I suppose it was an hardware problem or something like that. Sorry for bothering you. Thanks Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Touchpad does not work anymore
On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote: > On Apr 1, 2005 11:43 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote: > > > On Apr 1, 2005 11:14 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > > > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > > > It works, too. Which one is the best one? > > > > > > > > > > > > > > > > Both of them are needed as they address two different problems. > > > > > > > > > I tried to boot with the 2 patches applied (and the patch which solves > > > > noresume) and now touchpad/touchpoint no longer works (with this > > > > kernel or with an older kernel). > > > > > > > > > > Could you be more explicit - it is not recognized at all or it is > > > recognized but mouse pointer does not move or something else? dmesg > > > also might be interesting. > > > > > It is recognized in dmesg (same message as before), but the mouse > > pointer does not move (a `cat /dev/input/mice` doesn't do anything). > > > > Should work... The patches come into play only when > suspending/resuming. So you are saying even with an old, unpatched > kernel ALS stopped working, right? > I did a suspend/resume with the patches applied. And yes it doesn't work with an old unpatched kernel. Detected in dmesg, but no movement. > Hmm, that USB mouse - was it there before? I wonder if "usb-handoff" > on the kernel comman line will help. > I plugged it after i saw the touchpad didn't worked anymore (and i test if the touchpad works without the mouse plugged in). > -- > Dmitry -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Touchpad does not work anymore
On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
> On Apr 1, 2005 11:14 AM, Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > > > It works, too. Which one is the best one?
> > > >
> > >
> > > Both of them are needed as they address two different problems.
> > >
> > I tried to boot with the 2 patches applied (and the patch which solves
> > noresume) and now touchpad/touchpoint no longer works (with this
> > kernel or with an older kernel).
> >
>
> Could you be more explicit - it is not recognized at all or it is
> recognized but mouse pointer does not move or something else? dmesg
> also might be interesting.
>
It is recognized in dmesg (same message as before), but the mouse
pointer does not move (a `cat /dev/input/mice` doesn't do anything).
By the way, it is a dell D600.
> Also, the 2nd "patch" was never published, could you post what exactly
> you have applied?
>
attached
> Thanks!
>
> --
> Dmitry
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
Input: serio - do not attempt to immediately disconnect port if
resume failed, let kseriod take care of it. Otherwise we
may attempt to unregister associated input devices which
will generate hotplug events which are not handled well
during swsusp.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
serio.c |1 -
1 files changed, 1 deletion(-)
Index: dtor/drivers/input/serio/serio.c
===
--- dtor.orig/drivers/input/serio/serio.c
+++ dtor/drivers/input/serio/serio.c
@@ -779,7 +779,6 @@ static int serio_resume(struct device *d
struct serio *serio = to_serio_port(dev);
if (!serio->drv || !serio->drv->reconnect ||
serio->drv->reconnect(serio)) {
- serio_disconnect_port(serio);
/*
* Driver re-probing can take a while, so better let kseriod
* deal with it.
--- ./drivers/input/mouse/alps.c.orig 2005-03-31 12:35:55.0 -0500
+++ ./drivers/input/mouse/alps.c2005-03-31 12:36:50.0 -0500
@@ -341,6 +341,8 @@ static int alps_reconnect(struct psmouse
unsigned char param[4];
int version;
+ psmouse_reset(psmouse);
+
if (!(priv->i = alps_get_model(psmouse, )))
return -1;
--- clean/kernel/power/swsusp.c 2005-03-19 00:32:32.0 +0100
+++ linux/kernel/power/swsusp.c 2005-04-01 00:23:15.0 +0200
@@ -1376,16 +1371,6 @@
{
int error;
- if (!swsusp_resume_device) {
- if (!strlen(resume_file))
- return -ENOENT;
- swsusp_resume_device = name_to_dev_t(resume_file);
- pr_debug("swsusp: Resume From Partition %s\n", resume_file);
- } else {
- pr_debug("swsusp: Resume From Partition %d:%d\n",
-MAJOR(swsusp_resume_device),
MINOR(swsusp_resume_device));
- }
-
resume_bdev = open_by_devnum(swsusp_resume_device, FMODE_READ);
if (!IS_ERR(resume_bdev)) {
set_blocksize(resume_bdev, PAGE_SIZE);
--- clean/kernel/power/disk.c 2005-03-19 00:32:32.0 +0100
+++ linux/kernel/power/disk.c 2005-04-01 00:23:09.0 +0200
@@ -233,6 +237,16 @@
{
int error;
+ if (!swsusp_resume_device) {
+ if (!strlen(resume_file))
+ return -ENOENT;
+ swsusp_resume_device = name_to_dev_t(resume_file);
+ pr_debug("swsusp: Resume From Partition %s\n", resume_file);
+ } else {
+ pr_debug("swsusp: Resume From Partition %d:%d\n",
+MAJOR(swsusp_resume_device),
MINOR(swsusp_resume_device));
+ }
+
if (noresume) {
/**
* FIXME: If noresume is specified, we need to find the
partition
:00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller
(rev 03)
Flags: bus master, fast devsel, latency 0
Memory at e000 (32-bit, prefetchable)
Capabilities: [e4] #09 [4104]
Capabilities: [a0] AGP version 2.0
:00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller
(rev 03) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: fc00-fdff
Prefetchable memory behind bridge: e800-efff
Expansion ROM at c000 [disabled] [size=4K]
:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev
Re: 2.6.12-rc1 swsusp broken [Was Re: swsusp not working for me on a PREEMPT 2.6.12-rc1 and 2.6.12-rc1-mm3 kernel]
On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > It works, too. Which one is the best one? > > > > Both of them are needed as they address two different problems. > I tried to boot with the 2 patches applied (and the patch which solves noresume) and now touchpad/touchpoint no longer works (with this kernel or with an older kernel). Were the 2 patches safe or is it unrelated ? Is there an easy way to get the touchpad back ? regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1 swsusp broken [Was Re: swsusp not working for me on a PREEMPT 2.6.12-rc1 and 2.6.12-rc1-mm3 kernel]
On Mar 31, 2005 8:09 PM, Dmitry Torokhov [EMAIL PROTECTED] wrote: It works, too. Which one is the best one? Both of them are needed as they address two different problems. I tried to boot with the 2 patches applied (and the patch which solves noresume) and now touchpad/touchpoint no longer works (with this kernel or with an older kernel). Were the 2 patches safe or is it unrelated ? Is there an easy way to get the touchpad back ? regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Touchpad does not work anymore
On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
On Apr 1, 2005 11:14 AM, Benoit Boissinot [EMAIL PROTECTED] wrote:
On Mar 31, 2005 8:09 PM, Dmitry Torokhov [EMAIL PROTECTED] wrote:
It works, too. Which one is the best one?
Both of them are needed as they address two different problems.
I tried to boot with the 2 patches applied (and the patch which solves
noresume) and now touchpad/touchpoint no longer works (with this
kernel or with an older kernel).
Could you be more explicit - it is not recognized at all or it is
recognized but mouse pointer does not move or something else? dmesg
also might be interesting.
It is recognized in dmesg (same message as before), but the mouse
pointer does not move (a `cat /dev/input/mice` doesn't do anything).
By the way, it is a dell D600.
Also, the 2nd patch was never published, could you post what exactly
you have applied?
attached
Thanks!
--
Dmitry
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
Input: serio - do not attempt to immediately disconnect port if
resume failed, let kseriod take care of it. Otherwise we
may attempt to unregister associated input devices which
will generate hotplug events which are not handled well
during swsusp.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
serio.c |1 -
1 files changed, 1 deletion(-)
Index: dtor/drivers/input/serio/serio.c
===
--- dtor.orig/drivers/input/serio/serio.c
+++ dtor/drivers/input/serio/serio.c
@@ -779,7 +779,6 @@ static int serio_resume(struct device *d
struct serio *serio = to_serio_port(dev);
if (!serio-drv || !serio-drv-reconnect ||
serio-drv-reconnect(serio)) {
- serio_disconnect_port(serio);
/*
* Driver re-probing can take a while, so better let kseriod
* deal with it.
--- ./drivers/input/mouse/alps.c.orig 2005-03-31 12:35:55.0 -0500
+++ ./drivers/input/mouse/alps.c2005-03-31 12:36:50.0 -0500
@@ -341,6 +341,8 @@ static int alps_reconnect(struct psmouse
unsigned char param[4];
int version;
+ psmouse_reset(psmouse);
+
if (!(priv-i = alps_get_model(psmouse, version)))
return -1;
--- clean/kernel/power/swsusp.c 2005-03-19 00:32:32.0 +0100
+++ linux/kernel/power/swsusp.c 2005-04-01 00:23:15.0 +0200
@@ -1376,16 +1371,6 @@
{
int error;
- if (!swsusp_resume_device) {
- if (!strlen(resume_file))
- return -ENOENT;
- swsusp_resume_device = name_to_dev_t(resume_file);
- pr_debug(swsusp: Resume From Partition %s\n, resume_file);
- } else {
- pr_debug(swsusp: Resume From Partition %d:%d\n,
-MAJOR(swsusp_resume_device),
MINOR(swsusp_resume_device));
- }
-
resume_bdev = open_by_devnum(swsusp_resume_device, FMODE_READ);
if (!IS_ERR(resume_bdev)) {
set_blocksize(resume_bdev, PAGE_SIZE);
--- clean/kernel/power/disk.c 2005-03-19 00:32:32.0 +0100
+++ linux/kernel/power/disk.c 2005-04-01 00:23:09.0 +0200
@@ -233,6 +237,16 @@
{
int error;
+ if (!swsusp_resume_device) {
+ if (!strlen(resume_file))
+ return -ENOENT;
+ swsusp_resume_device = name_to_dev_t(resume_file);
+ pr_debug(swsusp: Resume From Partition %s\n, resume_file);
+ } else {
+ pr_debug(swsusp: Resume From Partition %d:%d\n,
+MAJOR(swsusp_resume_device),
MINOR(swsusp_resume_device));
+ }
+
if (noresume) {
/**
* FIXME: If noresume is specified, we need to find the
partition
:00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller
(rev 03)
Flags: bus master, fast devsel, latency 0
Memory at e000 (32-bit, prefetchable)
Capabilities: [e4] #09 [4104]
Capabilities: [a0] AGP version 2.0
:00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller
(rev 03) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: fc00-fdff
Prefetchable memory behind bridge: e800-efff
Expansion ROM at c000 [disabled] [size=4K]
:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
Subsystem: Intel Corporation: Unknown device 4541
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at bf80 [size=32]
:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M
Re: Touchpad does not work anymore
On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote: On Apr 1, 2005 11:43 AM, Benoit Boissinot [EMAIL PROTECTED] wrote: On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote: On Apr 1, 2005 11:14 AM, Benoit Boissinot [EMAIL PROTECTED] wrote: On Mar 31, 2005 8:09 PM, Dmitry Torokhov [EMAIL PROTECTED] wrote: It works, too. Which one is the best one? Both of them are needed as they address two different problems. I tried to boot with the 2 patches applied (and the patch which solves noresume) and now touchpad/touchpoint no longer works (with this kernel or with an older kernel). Could you be more explicit - it is not recognized at all or it is recognized but mouse pointer does not move or something else? dmesg also might be interesting. It is recognized in dmesg (same message as before), but the mouse pointer does not move (a `cat /dev/input/mice` doesn't do anything). Should work... The patches come into play only when suspending/resuming. So you are saying even with an old, unpatched kernel ALS stopped working, right? I did a suspend/resume with the patches applied. And yes it doesn't work with an old unpatched kernel. Detected in dmesg, but no movement. Hmm, that USB mouse - was it there before? I wonder if usb-handoff on the kernel comman line will help. I plugged it after i saw the touchpad didn't worked anymore (and i test if the touchpad works without the mouse plugged in). -- Dmitry -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sound/oss/: cleanups
On Tue, 29 Mar 2005 00:03:07 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Mon, Mar 28, 2005 at 03:55:36PM -0500, Benoit Boissinot wrote: > > On Sun, 6 Mar 2005 23:07:47 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > This patch contains cleanups including the following: > > > - make needlessly global code static > > > > That's a different problem. > Please apply the patch below on top of my other patch. > > <-- snip --> > > Rearrange sound/oss/nm256_audio.c and to drop nm256_debug from nm256.h > since it confuses gcc 4.0 . Could this patch go in -mm (it is needed for allyesconfig and gcc-4). Thanks, Benoit > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- linux-2.6.12-rc1-mm3-full/sound/oss/nm256.h.old 2005-03-28 > 23:49:39.0 +0200 > +++ linux-2.6.12-rc1-mm3-full/sound/oss/nm256.h 2005-03-28 23:51:33.0 > +0200 > @@ -128,9 +128,6 @@ > struct nm256_info *next_card; > }; > > -/* Debug flag--bigger numbers mean more output. */ > -extern int nm256_debug; > - > /* The BIOS signature. */ > #define NM_SIGNATURE 0x4e4d > /* Signature mask. */ > --- linux-2.6.12-rc1-mm3-full/sound/oss/nm256_audio.c.old 2005-03-28 > 23:51:53.0 +0200 > +++ linux-2.6.12-rc1-mm3-full/sound/oss/nm256_audio.c 2005-03-28 > 23:52:19.0 +0200 > @@ -28,12 +28,13 @@ > #include > #include > #include "sound_config.h" > -#include "nm256.h" > -#include "nm256_coeff.h" > > static int nm256_debug; > static int force_load; > > +#include "nm256.h" > +#include "nm256_coeff.h" > + > /* > * The size of the playback reserve. When the playback buffer has less > * than NM256_PLAY_WMARK_SIZE bytes to output, we request a new > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Keys: Make request-key create an authorisation key
On Wed, 23 Mar 2005 20:52:45 +, David Howells <[EMAIL PROTECTED]> wrote:
>
> The attached patch makes the following changes:
>
> (6) One of the process keyrings can be nominated as the default to which
> request_key() should attach new keys if not otherwise specified. This is
> done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
> constants. The current setting can also be read using this call.
>
>
> Signed-Off-By: David Howells <[EMAIL PROTECTED]>
> ---
> @@ -903,6 +922,44 @@ long keyctl_negate_key(key_serial_t id,
>
>
> /*/
> /*
> + * set the default keyring in which request_key() will cache keys
> + * - return the old setting
> + */
> +long keyctl_set_reqkey_keyring(int reqkey_defl)
> +{
> + int ret;
> +
> + switch (reqkey_defl) {
> + case KEY_REQKEY_DEFL_THREAD_KEYRING:
> + ret = install_thread_keyring(current);
> + if (ret < 0)
> + return ret;
> + goto set;
> +
> + case KEY_REQKEY_DEFL_PROCESS_KEYRING:
> + ret = install_process_keyring(current);
> + if (ret < 0)
> + return ret;
> +
> + case KEY_REQKEY_DEFL_DEFAULT:
> + case KEY_REQKEY_DEFL_SESSION_KEYRING:
> + case KEY_REQKEY_DEFL_USER_KEYRING:
> + case KEY_REQKEY_DEFL_USER_SESSION_KEYRING:
> + set:
> + current->jit_keyring = reqkey_defl;
> +
> + case KEY_REQKEY_DEFL_NO_CHANGE:
> + return current->jit_keyring;
> +
> + case KEY_SPEC_GROUP_KEYRING:
KEY_REQKEY_DEFL__GROUP_KEYRING
> + default:
> + return -EINVAL;
> + }
> +
> +} /* end keyctl_set_reqkey_keyring() */
> +
> @@ -267,21 +294,84 @@ static struct key *request_key_construct
>
>
> /*/
> /*
> + * link a freshly minted key to an appropriate destination keyring
> + */
> +static void request_key_link(struct key *key, struct key *dest_keyring)
> +{
> + struct task_struct *tsk = current;
> + struct key *drop = NULL;
> +
> + kenter("{%d},%p", key->serial, dest_keyring);
> +
> + /* find the appropriate keyring */
> + if (!dest_keyring) {
> + switch (tsk->jit_keyring) {
> + case KEY_REQKEY_DEFL_DEFAULT:
> + case KEY_REQKEY_DEFL_THREAD_KEYRING:
> + dest_keyring = tsk->thread_keyring;
> + if (dest_keyring)
> + break;
> +
> + case KEY_REQKEY_DEFL_PROCESS_KEYRING:
> + dest_keyring = tsk->signal->process_keyring;
> + if (dest_keyring)
> + break;
> +
> + case KEY_REQKEY_DEFL_SESSION_KEYRING:
> + rcu_read_lock();
> + dest_keyring = key_get(
> +
> rcu_dereference(tsk->signal->session_keyring));
> + rcu_read_unlock();
> + drop = dest_keyring;
> +
> + if (dest_keyring)
> + break;
> +
> + case KEY_REQKEY_DEFL_USER_SESSION_KEYRING:
> + dest_keyring = current->user->session_keyring;
> + break;
> +
> + case KEY_REQKEY_DEFL_USER_KEYRING:
> + dest_keyring = current->user->uid_keyring;
> + break;
> +
> + case KEY_REQKEY_DEFL_NO_CHANGE:
gcc-4 warns about this (warning: case label value is less than minimum
value for type) and it shouldn't be in jit_keyring anyway.
> + case KEY_SPEC_GROUP_KEYRING:
KEY_REQKEY_DEFL_GROUP_KEYRING
> + default:
> + BUG();
> + }
> + }
> +
> + /* and attach the key to it */
> + key_link(dest_keyring, key);
patch attached.
regards,
Benoit
keys.patch
Description: Binary data
Re: 2.6.12-rc1 swsusp broken [Was Re: swsusp not working for me on a PREEMPT 2.6.12-rc1 and 2.6.12-rc1-mm3 kernel]
On Thu, 31 Mar 2005 18:50:07 +0200, Romano Giannetti <[EMAIL PROTECTED]> wrote: > On Thu, Mar 31, 2005 at 10:15:26AM -0500, Dmitry Torokhov wrote: > > On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti <[EMAIL PROTECTED]> > > wrote: > > > > > > The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go. > > > > Ok, I see you have an ALPS touchpad. I think this patch will help you > > with swsusp: > > > > http://marc.theaimsgroup.com/?l=linux-kernel=111212532524998=raw > > Yes! With this it works ok. > > > Also, could you please try sticking psmouse_reset(psmouse) call at the > > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if > > it can suspend _without_ the patch above. > Both patches are working for me (Dell D600). before i was unable to suspend to disk on this laptop (it was stuck in alps code). By the way, i have an unrelated problem: if the kernel was booted with the "noresume" option, it cannot be suspended, it fails with: swsusp: FATAL: cannot find swap device, try swapon -a! Thanks, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1 swsusp broken [Was Re: swsusp not working for me on a PREEMPT 2.6.12-rc1 and 2.6.12-rc1-mm3 kernel]
On Thu, 31 Mar 2005 18:50:07 +0200, Romano Giannetti [EMAIL PROTECTED] wrote: On Thu, Mar 31, 2005 at 10:15:26AM -0500, Dmitry Torokhov wrote: On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti [EMAIL PROTECTED] wrote: The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go. Ok, I see you have an ALPS touchpad. I think this patch will help you with swsusp: http://marc.theaimsgroup.com/?l=linux-kernelm=111212532524998q=raw Yes! With this it works ok. Also, could you please try sticking psmouse_reset(psmouse) call at the beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if it can suspend _without_ the patch above. Both patches are working for me (Dell D600). before i was unable to suspend to disk on this laptop (it was stuck in alps code). By the way, i have an unrelated problem: if the kernel was booted with the noresume option, it cannot be suspended, it fails with: swsusp: FATAL: cannot find swap device, try swapon -a! Thanks, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Keys: Make request-key create an authorisation key
On Wed, 23 Mar 2005 20:52:45 +, David Howells [EMAIL PROTECTED] wrote:
The attached patch makes the following changes:
(6) One of the process keyrings can be nominated as the default to which
request_key() should attach new keys if not otherwise specified. This is
done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
constants. The current setting can also be read using this call.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
@@ -903,6 +922,44 @@ long keyctl_negate_key(key_serial_t id,
/*/
/*
+ * set the default keyring in which request_key() will cache keys
+ * - return the old setting
+ */
+long keyctl_set_reqkey_keyring(int reqkey_defl)
+{
+ int ret;
+
+ switch (reqkey_defl) {
+ case KEY_REQKEY_DEFL_THREAD_KEYRING:
+ ret = install_thread_keyring(current);
+ if (ret 0)
+ return ret;
+ goto set;
+
+ case KEY_REQKEY_DEFL_PROCESS_KEYRING:
+ ret = install_process_keyring(current);
+ if (ret 0)
+ return ret;
+
+ case KEY_REQKEY_DEFL_DEFAULT:
+ case KEY_REQKEY_DEFL_SESSION_KEYRING:
+ case KEY_REQKEY_DEFL_USER_KEYRING:
+ case KEY_REQKEY_DEFL_USER_SESSION_KEYRING:
+ set:
+ current-jit_keyring = reqkey_defl;
+
+ case KEY_REQKEY_DEFL_NO_CHANGE:
+ return current-jit_keyring;
+
+ case KEY_SPEC_GROUP_KEYRING:
KEY_REQKEY_DEFL__GROUP_KEYRING
+ default:
+ return -EINVAL;
+ }
+
+} /* end keyctl_set_reqkey_keyring() */
+
@@ -267,21 +294,84 @@ static struct key *request_key_construct
/*/
/*
+ * link a freshly minted key to an appropriate destination keyring
+ */
+static void request_key_link(struct key *key, struct key *dest_keyring)
+{
+ struct task_struct *tsk = current;
+ struct key *drop = NULL;
+
+ kenter({%d},%p, key-serial, dest_keyring);
+
+ /* find the appropriate keyring */
+ if (!dest_keyring) {
+ switch (tsk-jit_keyring) {
+ case KEY_REQKEY_DEFL_DEFAULT:
+ case KEY_REQKEY_DEFL_THREAD_KEYRING:
+ dest_keyring = tsk-thread_keyring;
+ if (dest_keyring)
+ break;
+
+ case KEY_REQKEY_DEFL_PROCESS_KEYRING:
+ dest_keyring = tsk-signal-process_keyring;
+ if (dest_keyring)
+ break;
+
+ case KEY_REQKEY_DEFL_SESSION_KEYRING:
+ rcu_read_lock();
+ dest_keyring = key_get(
+
rcu_dereference(tsk-signal-session_keyring));
+ rcu_read_unlock();
+ drop = dest_keyring;
+
+ if (dest_keyring)
+ break;
+
+ case KEY_REQKEY_DEFL_USER_SESSION_KEYRING:
+ dest_keyring = current-user-session_keyring;
+ break;
+
+ case KEY_REQKEY_DEFL_USER_KEYRING:
+ dest_keyring = current-user-uid_keyring;
+ break;
+
+ case KEY_REQKEY_DEFL_NO_CHANGE:
gcc-4 warns about this (warning: case label value is less than minimum
value for type) and it shouldn't be in jit_keyring anyway.
+ case KEY_SPEC_GROUP_KEYRING:
KEY_REQKEY_DEFL_GROUP_KEYRING
+ default:
+ BUG();
+ }
+ }
+
+ /* and attach the key to it */
+ key_link(dest_keyring, key);
patch attached.
regards,
Benoit
keys.patch
Description: Binary data
Re: [2.6 patch] sound/oss/: cleanups
On Tue, 29 Mar 2005 00:03:07 +0200, Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Mar 28, 2005 at 03:55:36PM -0500, Benoit Boissinot wrote: On Sun, 6 Mar 2005 23:07:47 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: This patch contains cleanups including the following: - make needlessly global code static That's a different problem. Please apply the patch below on top of my other patch. -- snip -- Rearrange sound/oss/nm256_audio.c and to drop nm256_debug from nm256.h since it confuses gcc 4.0 . Could this patch go in -mm (it is needed for allyesconfig and gcc-4). Thanks, Benoit Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.12-rc1-mm3-full/sound/oss/nm256.h.old 2005-03-28 23:49:39.0 +0200 +++ linux-2.6.12-rc1-mm3-full/sound/oss/nm256.h 2005-03-28 23:51:33.0 +0200 @@ -128,9 +128,6 @@ struct nm256_info *next_card; }; -/* Debug flag--bigger numbers mean more output. */ -extern int nm256_debug; - /* The BIOS signature. */ #define NM_SIGNATURE 0x4e4d /* Signature mask. */ --- linux-2.6.12-rc1-mm3-full/sound/oss/nm256_audio.c.old 2005-03-28 23:51:53.0 +0200 +++ linux-2.6.12-rc1-mm3-full/sound/oss/nm256_audio.c 2005-03-28 23:52:19.0 +0200 @@ -28,12 +28,13 @@ #include linux/delay.h #include linux/spinlock.h #include sound_config.h -#include nm256.h -#include nm256_coeff.h static int nm256_debug; static int force_load; +#include nm256.h +#include nm256_coeff.h + /* * The size of the playback reserve. When the playback buffer has less * than NM256_PLAY_WMARK_SIZE bytes to output, we request a new - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.12-rc1-mm3] BUG: atomic counter underflow in smbfs
On Wed, Mar 30, 2005 at 12:44:56PM -0800, Andrew Morton wrote: > Benoit Boissinot <[EMAIL PROTECTED]> wrote: > > > > I had the following BUG with 2.6.12-rc1-mm3: > > > > remote host is running 2.6.12-rc1-mm1 with samba 3.0.13. > > > > [23156.357178] smb_lookup: find musique/Pink_Floyd-Dark_Side_of_the_Moon > > failed, error=-512 > > [23157.057501] BUG: atomic counter underflow at: > > [23157.057508] [] dump_stack+0x17/0x20 > > [23157.057516] [] smb_rput+0x51/0x60 [smbfs] > > [23157.057530] [] smb_proc_query_cifsunix+0x77/0xa0 [smbfs] > > [23157.057538] [] smb_newconn+0x2bc/0x310 [smbfs] > > [23157.057546] [] smb_ioctl+0xfc/0x100 [smbfs] > > [23157.057554] [] do_ioctl+0x48/0x70 > > [23157.057559] [] vfs_ioctl+0x59/0x1b0 > > [23157.057563] [] sys_ioctl+0x39/0x60 > > [23157.057582] [] sysenter_past_esp+0x54/0x75 > > Oh dear. That warning is not necessarily telling us that there's a serious > problem - often it's fairly harmless. Did the filesytem misbehave in any > other manner? > It was stucked (couldn't do anything inside) but i was able to umount it. > A problem we have here is that nobody really maintains smbfs any more, and > it has problems. I was hoping that the stock answer to that would be "use > cifs", but for some reason that doesn't seem to be happening. Have you > tried it? (Last time I looked, cifs didn't work against win98 servers - > maybe that got fixed). > > Ok, i think i will google a bit to find how to use samba as a cifs server. Thanks, Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.12-rc1-mm3] BUG: atomic counter underflow in smbfs
I had the following BUG with 2.6.12-rc1-mm3: remote host is running 2.6.12-rc1-mm1 with samba 3.0.13. [23156.357178] smb_lookup: find musique/Pink_Floyd-Dark_Side_of_the_Moon failed, error=-512 [23157.057501] BUG: atomic counter underflow at: [23157.057508] [] dump_stack+0x17/0x20 [23157.057516] [] smb_rput+0x51/0x60 [smbfs] [23157.057530] [] smb_proc_query_cifsunix+0x77/0xa0 [smbfs] [23157.057538] [] smb_newconn+0x2bc/0x310 [smbfs] [23157.057546] [] smb_ioctl+0xfc/0x100 [smbfs] [23157.057554] [] do_ioctl+0x48/0x70 [23157.057559] [] vfs_ioctl+0x59/0x1b0 [23157.057563] [] sys_ioctl+0x39/0x60 [23157.057582] [] sysenter_past_esp+0x54/0x75 Feel free to ask if you need more informations. regards, Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS config.gz Description: application/gunzip
[2.6.12-rc1-mm3] BUG: atomic counter underflow in smbfs
I had the following BUG with 2.6.12-rc1-mm3: remote host is running 2.6.12-rc1-mm1 with samba 3.0.13. [23156.357178] smb_lookup: find musique/Pink_Floyd-Dark_Side_of_the_Moon failed, error=-512 [23157.057501] BUG: atomic counter underflow at: [23157.057508] [c0103c27] dump_stack+0x17/0x20 [23157.057516] [e0ed0f31] smb_rput+0x51/0x60 [smbfs] [23157.057530] [e0ecd497] smb_proc_query_cifsunix+0x77/0xa0 [smbfs] [23157.057538] [e0eca14c] smb_newconn+0x2bc/0x310 [smbfs] [23157.057546] [e0ed05ac] smb_ioctl+0xfc/0x100 [smbfs] [23157.057554] [c0162188] do_ioctl+0x48/0x70 [23157.057559] [c01622f9] vfs_ioctl+0x59/0x1b0 [23157.057563] [c0162489] sys_ioctl+0x39/0x60 [23157.057582] [c0102d8f] sysenter_past_esp+0x54/0x75 Feel free to ask if you need more informations. regards, Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS config.gz Description: application/gunzip
Re: [2.6.12-rc1-mm3] BUG: atomic counter underflow in smbfs
On Wed, Mar 30, 2005 at 12:44:56PM -0800, Andrew Morton wrote: Benoit Boissinot [EMAIL PROTECTED] wrote: I had the following BUG with 2.6.12-rc1-mm3: remote host is running 2.6.12-rc1-mm1 with samba 3.0.13. [23156.357178] smb_lookup: find musique/Pink_Floyd-Dark_Side_of_the_Moon failed, error=-512 [23157.057501] BUG: atomic counter underflow at: [23157.057508] [c0103c27] dump_stack+0x17/0x20 [23157.057516] [e0ed0f31] smb_rput+0x51/0x60 [smbfs] [23157.057530] [e0ecd497] smb_proc_query_cifsunix+0x77/0xa0 [smbfs] [23157.057538] [e0eca14c] smb_newconn+0x2bc/0x310 [smbfs] [23157.057546] [e0ed05ac] smb_ioctl+0xfc/0x100 [smbfs] [23157.057554] [c0162188] do_ioctl+0x48/0x70 [23157.057559] [c01622f9] vfs_ioctl+0x59/0x1b0 [23157.057563] [c0162489] sys_ioctl+0x39/0x60 [23157.057582] [c0102d8f] sysenter_past_esp+0x54/0x75 Oh dear. That warning is not necessarily telling us that there's a serious problem - often it's fairly harmless. Did the filesytem misbehave in any other manner? It was stucked (couldn't do anything inside) but i was able to umount it. A problem we have here is that nobody really maintains smbfs any more, and it has problems. I was hoping that the stock answer to that would be use cifs, but for some reason that doesn't seem to be happening. Have you tried it? (Last time I looked, cifs didn't work against win98 servers - maybe that got fixed). Ok, i think i will google a bit to find how to use samba as a cifs server. Thanks, Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sound/oss/: cleanups
On Sun, 6 Mar 2005 23:07:47 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote: > This patch contains cleanups including the following: > - make needlessly global code static > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- linux-2.6.11-mm1-full/sound/oss/nm256_audio.c.old 2005-03-06 > 22:14:42.0 +0100 > +++ linux-2.6.11-mm1-full/sound/oss/nm256_audio.c 2005-03-06 > 22:22:52.0 +0100 > @@ -31,7 +31,7 @@ > #include "nm256.h" > #include "nm256_coeff.h" > > -int nm256_debug; > +static int nm256_debug; > static int force_load; > > /* nm256_debug is used in functions declared in nm256.h (those functions are used in nm256_coeff.h and nm256_audio.c). This part of the patch should be dropped (it doesn't build on gcc-4.0). regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sound/oss/: cleanups
On Sun, 6 Mar 2005 23:07:47 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: This patch contains cleanups including the following: - make needlessly global code static Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.11-mm1-full/sound/oss/nm256_audio.c.old 2005-03-06 22:14:42.0 +0100 +++ linux-2.6.11-mm1-full/sound/oss/nm256_audio.c 2005-03-06 22:22:52.0 +0100 @@ -31,7 +31,7 @@ #include nm256.h #include nm256_coeff.h -int nm256_debug; +static int nm256_debug; static int force_load; /* nm256_debug is used in functions declared in nm256.h (those functions are used in nm256_coeff.h and nm256_audio.c). This part of the patch should be dropped (it doesn't build on gcc-4.0). regards, Benoit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm4
On Wed, Mar 16, 2005 at 04:06:54AM -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm4/ > > - fbdev update > It doesn't compile with gcc-4.0. drivers/video/console/fbcon.c:133: error: static declaration of âfb_conâ follows non-static declaration drivers/video/console/fbcon.h:166: error: previous declaration of âfb_conâ was here Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> --- linux-test/drivers/video/console/fbcon.h2005-03-16 15:15:57.0 +0100 +++ linux/drivers/video/console/fbcon.h 2005-03-16 15:14:18.0 +0100 @@ -163,6 +163,4 @@ extern void fbcon_set_tileops(struct vc_ #endif extern void fbcon_set_bitops(struct fbcon_ops *ops); -extern const struct consw fb_con; - #endif /* _VIDEO_FBCON_H */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-mm4
On Wed, Mar 16, 2005 at 04:06:54AM -0800, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm4/ - fbdev update It doesn't compile with gcc-4.0. drivers/video/console/fbcon.c:133: error: static declaration of fb_con follows non-static declaration drivers/video/console/fbcon.h:166: error: previous declaration of fb_con was here Signed-off-by: Benoit Boissinot [EMAIL PROTECTED] --- linux-test/drivers/video/console/fbcon.h2005-03-16 15:15:57.0 +0100 +++ linux/drivers/video/console/fbcon.h 2005-03-16 15:14:18.0 +0100 @@ -163,6 +163,4 @@ extern void fbcon_set_tileops(struct vc_ #endif extern void fbcon_set_bitops(struct fbcon_ops *ops); -extern const struct consw fb_con; - #endif /* _VIDEO_FBCON_H */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] fix NULL pointer deference in ALPS
On Mon, Mar 07, 2005 at 04:06:33PM +0200, Alexey Dobriyan wrote: > On Monday 07 March 2005 14:24, Benoit Boissinot wrote: > > > alps_get_model returns a pointer or NULL in case of errors, so we need to > > check for the results being NULL, not negative. > > 2.6.11-bk2: int alps_get_model(struct psmouse *psmouse) > takes 1 argument, returns -1 on error > > 2.6.11-mm1: static struct alps_model_info *alps_get_model(struct psmouse > *psmouse, int *version) > takes 2 arguments, returns NULL on error > Sorry, i misreaded the vanilla code, it only applies to -mm. Since it seems to be fixed in bk-input, please forget the patch. Sorry. Benoit -- powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] fix NULL pointer deference in ALPS
I get a NULL pointer deference in with alps while suspending.
The following patch fixes it: alps_get_model returns a pointer or
NULL in case of errors, so we need to check for the results being NULL,
not negative.
Since it is trivial, it is maybe a candidate for 2.6.11.2.
It does not apply to -mm since the last occurence of alps_get_model
was corrected (but not the others), if needed i can send a patch for
-mm as well.
regards,
Benoit
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- linux-clean/drivers/input/mouse/alps.c 2005-03-07 12:45:46.0
+0100
+++ linux-vanilla/drivers/input/mouse/alps.c2005-03-07 12:50:12.0
+0100
@@ -325,7 +325,7 @@ static int alps_reconnect(struct psmouse
int model;
unsigned char param[4];
- if ((model = alps_get_model(psmouse)) < 0)
+ if (!(model = alps_get_model(psmouse)))
return -1;
if (model == ALPS_MODEL_DUALPOINT && alps_passthrough_mode(psmouse, 1))
@@ -358,7 +358,7 @@ int alps_init(struct psmouse *psmouse)
unsigned char param[4];
int model;
- if ((model = alps_get_model(psmouse)) < 0)
+ if (!(model = alps_get_model(psmouse)))
return -1;
printk(KERN_INFO "ALPS Touchpad (%s) detected\n",
@@ -412,7 +412,7 @@ int alps_init(struct psmouse *psmouse)
int alps_detect(struct psmouse *psmouse, int set_properties)
{
- if (alps_get_model(psmouse) < 0)
+ if (!alps_get_model(psmouse))
return -1;
if (set_properties) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
