Re: 2.6.13-rc6-mm1
Reuben Farrelly <[EMAIL PROTECTED]> wrote: > > Hi, > > On 19/08/2005 11:37 a.m., Andrew Morton 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: > > > > linus.patch > > Noted this in my log earlier today. > > Is this inotify related? > > Aug 21 08:33:04 tornado kernel: idr_remove called for id=2048 which is not > allocated. > Aug 21 08:33:04 tornado kernel: [] dump_stack+0x17/0x19 > Aug 21 08:33:04 tornado kernel: [] idr_remove_warning+0x1b/0x1d > Aug 21 08:33:04 tornado kernel: [] sub_remove+0x88/0xea > Aug 21 08:33:04 tornado kernel: [] idr_remove+0x1b/0x7f > Aug 21 08:33:04 tornado kernel: [] remove_watch_no_event+0x7a/0x12e > Aug 21 08:33:04 tornado kernel: [] inotify_release+0x8f/0x1af > Aug 21 08:33:04 tornado kernel: [] __fput+0xaf/0x199 > Aug 21 08:33:04 tornado kernel: [] fput+0x22/0x3b > Aug 21 08:33:04 tornado kernel: [] filp_close+0x41/0x67 > Aug 21 08:33:04 tornado kernel: [] sys_close+0x70/0x92 > Aug 21 08:33:04 tornado kernel: [] sysenter_past_esp+0x54/0x75 > Aug 21 08:33:04 tornado kernel: idr_remove called for id=3072 which is not > allocated. > Aug 21 08:33:05 tornado kernel: [] dump_stack+0x17/0x19 > Aug 21 08:33:05 tornado kernel: [] idr_remove_warning+0x1b/0x1d > Aug 21 08:33:05 tornado kernel: [] sub_remove+0x88/0xea > Aug 21 08:33:05 tornado kernel: [] idr_remove+0x1b/0x7f > Aug 21 08:33:05 tornado kernel: [] remove_watch_no_event+0x7a/0x12e > Aug 21 08:33:05 tornado kernel: [] inotify_release+0x8f/0x1af > Aug 21 08:33:05 tornado kernel: [] __fput+0xaf/0x199 > Aug 21 08:33:05 tornado kernel: [] fput+0x22/0x3b > Aug 21 08:33:05 tornado kernel: [] filp_close+0x41/0x67 > Aug 21 08:33:05 tornado kernel: [] sys_close+0x70/0x92 > Aug 21 08:33:05 tornado kernel: [] sysenter_past_esp+0x54/0x75 > > This would have been triggered by using dovecot IMAP which is configured to > use inotify on Maildir. > I'm also seeing some userspace errors logged for dovecot: > > "Aug 21 04:17:22 Error: IMAP(reuben): inotify_rm_watch() failed: Invalid > argument" > > I'll deal with those with the guy who wrote the inotify code in dovecot. > > I'm not so sure userspace should be able or need to cause the kernel to dump > stack traces like that though? > Yes, the stack dumps would appear to be due to an inotify bug. The message from dovecot is allegedly due to dovecot passing in a file descriptor which was not obtained from the inotify_init() syscall. But until we know what caused those stack dumps we cannot definitely say whether dovecot is at fault. - 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.5 stalls on boot
2.6.12.5 and others below that to 2.6.10 stall on boot. The problem is udev. It stalls between 1 to 3 minutes. I have the latest udev hotplug klibc u name it Something happened about 2.6.11.X and I see others writing about similar items The base system is Suse 9.2 and I am beginning to wonder if there is something that Suse wrote that is interferring w/the boot. Since they shipped 9.2 with a 2.6.8-24 and there have been a lot of changes up to 2.6.12.5 In any case the boot stalls just after it prints these two lines input: AT Translated Set 2 keyboard on isa0060/serio0 input: PS/2 Generic Mouse on isa0060/serio4 and about 2 mins + - later it prints this EXT2-fs warning (device hda6): ext2_fill_super: mounting ext3 filesystem as ext2 and then continue normal boot I sent in an ALT SYSREQ P and T trace a few weeks ago but didnt get an answer. Am I incorrect in assuming that everything up until the root disk is mounted is primarily kernel activity? If not then where else can I look. I can provide any info desired. Just in case this is Suse related I am going to load 9.3 early next week and compile 2.6.12.5 on it and see it I encounter the stall problem. I will post the results from the activity. - 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
Hi, On 19/08/2005 11:37 a.m., Andrew Morton 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: linus.patch Noted this in my log earlier today. Is this inotify related? Aug 21 08:33:04 tornado kernel: idr_remove called for id=2048 which is not allocated. Aug 21 08:33:04 tornado kernel: [] dump_stack+0x17/0x19 Aug 21 08:33:04 tornado kernel: [] idr_remove_warning+0x1b/0x1d Aug 21 08:33:04 tornado kernel: [] sub_remove+0x88/0xea Aug 21 08:33:04 tornado kernel: [] idr_remove+0x1b/0x7f Aug 21 08:33:04 tornado kernel: [] remove_watch_no_event+0x7a/0x12e Aug 21 08:33:04 tornado kernel: [] inotify_release+0x8f/0x1af Aug 21 08:33:04 tornado kernel: [] __fput+0xaf/0x199 Aug 21 08:33:04 tornado kernel: [] fput+0x22/0x3b Aug 21 08:33:04 tornado kernel: [] filp_close+0x41/0x67 Aug 21 08:33:04 tornado kernel: [] sys_close+0x70/0x92 Aug 21 08:33:04 tornado kernel: [] sysenter_past_esp+0x54/0x75 Aug 21 08:33:04 tornado kernel: idr_remove called for id=3072 which is not allocated. Aug 21 08:33:05 tornado kernel: [] dump_stack+0x17/0x19 Aug 21 08:33:05 tornado kernel: [] idr_remove_warning+0x1b/0x1d Aug 21 08:33:05 tornado kernel: [] sub_remove+0x88/0xea Aug 21 08:33:05 tornado kernel: [] idr_remove+0x1b/0x7f Aug 21 08:33:05 tornado kernel: [] remove_watch_no_event+0x7a/0x12e Aug 21 08:33:05 tornado kernel: [] inotify_release+0x8f/0x1af Aug 21 08:33:05 tornado kernel: [] __fput+0xaf/0x199 Aug 21 08:33:05 tornado kernel: [] fput+0x22/0x3b Aug 21 08:33:05 tornado kernel: [] filp_close+0x41/0x67 Aug 21 08:33:05 tornado kernel: [] sys_close+0x70/0x92 Aug 21 08:33:05 tornado kernel: [] sysenter_past_esp+0x54/0x75 This would have been triggered by using dovecot IMAP which is configured to use inotify on Maildir. I'm also seeing some userspace errors logged for dovecot: "Aug 21 04:17:22 Error: IMAP(reuben): inotify_rm_watch() failed: Invalid argument" I'll deal with those with the guy who wrote the inotify code in dovecot. I'm not so sure userspace should be able or need to cause the kernel to dump stack traces like that though? reuben - 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
Hi, On 21/08/2005 1:40 a.m., David Woodhouse wrote: On Fri, 2005-08-19 at 18:36 -0700, Andrew Morton wrote: Reuben Farrelly <[EMAIL PROTECTED]> wrote: ... 4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor ted" and I can't log in as any user including root. I would have picked this was a userspace problem, but it doesn't break with -rc5-mm1, yet reproduceably breaks with -rc6-mm1. Weird. hm. How come you're able to use the machine then? Machine was booting up ok, and things were being written to syslog. Rebooted into -rc5-mm1 to investigate, and of course could boot into rc6-mm1 in single user mode, test and bring services up one by one from there. Having two boxes helped too. Is it possible to get an strace of this failure somehow? Not sure if this is needed anymore, as I found that the problem goes away when I compile in kernel auditing. This not required for -rc5-mm1. Is that change intended? Sounds wrong to me, especially if 2.6.13-rc6 doesn't do that. Hm. It sounds like you'd configured PAM to require the pam_loginuid module even though you didn't have auditing enabled in your kernel. That seems strange and wrong to me, and _is_ a userspace problem. I haven't touched my pam config since it was installed a long time ago - it's one of those things that is too annoying to fix once broked, so I leave it alone at the system defaults ;) I had logged this as a Fedora bug as I figured the pam_loginuid detection of the presence of auditing in the kernel is not very robust. There was a patch modified in pam-0.80-6 at the start of August which was to fix this on non audit enabled kernels, which works for anything up to and older than 2.6.12-rc5-mm1. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166422 It was closed 8 mins later, and the suggestion made that I take it to a pam development list instead. Redhat don't seem so interested in fixing things as a result of breakage when running an -mm kernel. I'd also agree that it shouldn't have changed with the new kernel though -- and I can't think of anything I changed recently which would have that effect. An strace would still be useful. Done. Posted up at http://www.reub.net/kernel/strace-login Can you double-check that you didn't have auditing enabled in your older, working kernel? Definitely wasn't enabled. I still have the .config that I used to build -rc5-mm1 with and my original -rc6-mm1 and it reads: CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y Thanks for taking a look. Reuben - 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: s390 build fix.
On Sun, Aug 21, 2005 at 06:11:31AM +0100, Al Viro wrote:
> On Sun, Aug 21, 2005 at 12:38:39AM -0400, Dave Jones wrote:
> > {standard input}: Assembler messages:
> > {standard input}:397: Error: symbol `.Litfits' is already defined
> > {standard input}:585: Error: symbol `.Litfits' is already defined
> >
> > Newer gcc's inline this it seems, which blows up.
>
> Eeek... Much easier (and already sent to Linus):
Sure, that works for me too.
Dave
-
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.5: psmouse mouse detection doesn't work
On Sun, Aug 21, 2005 at 06:42:23AM +0200, Harald Dunkel wrote: > Hi folks, > > At boot time my Logitech mouse is detected as > > I: Bus=0011 Vendor=0002 Product=0001 Version= > N: Name="PS/2 Generic Mouse" > P: Phys=isa0060/serio1/input0 > H: Handlers=event1 ts0 mouse0 > B: EV=7 > B: KEY=7 0 0 0 0 > B: REL=3 > > After manually reloading psmouse I get the expected > > I: Bus=0011 Vendor=0002 Product=0002 Version=0049 > N: Name="PS2++ Logitech Mouse" > P: Phys=isa0060/serio1/input0 > H: Handlers=event1 ts0 mouse0 > B: EV=7 > B: KEY=f 0 0 0 0 > B: REL=3 > > Using psmouse_noext=1 at boot time does not help. > > How comes that this doesn't work on the first run? > > I asked this more than a year ago, and somebody posted > a fix, but obviously it wasn't accepted. > > What needs to be done to fix this? If psmouse is a module, you'd need to pass proto=bare as a module parameter rather than on the kernel command line. Check `modinfo psmouse`. Are you sure proto=imps hasn't found its way into /etc/modprobe.conf or so? I could imagine a distribution shipping this way. -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - 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.5: psmouse mouse detection doesn't work
On Saturday 20 August 2005 23:42, Harald Dunkel wrote: > Hi folks, > > At boot time my Logitech mouse is detected as > > I: Bus=0011 Vendor=0002 Product=0001 Version= > N: Name="PS/2 Generic Mouse" > P: Phys=isa0060/serio1/input0 > H: Handlers=event1 ts0 mouse0 > B: EV=7 > B: KEY=7 0 0 0 0 > B: REL=3 > > After manually reloading psmouse I get the expected > > I: Bus=0011 Vendor=0002 Product=0002 Version=0049 > N: Name="PS2++ Logitech Mouse" > P: Phys=isa0060/serio1/input0 > H: Handlers=event1 ts0 mouse0 > B: EV=7 > B: KEY=f 0 0 0 0 > B: REL=3 > Does booting with "usb-handoff" on the kernel boot line help? -- Dmitry - 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.5: psmouse mouse detection doesn't work
Harald Dunkel wrote: At boot time my Logitech mouse is detected as I: Bus=0011 Vendor=0002 Product=0001 Version= N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 H: Handlers=event1 ts0 mouse0 B: EV=7 B: KEY=7 0 0 0 0 B: REL=3 After manually reloading psmouse I get the expected I: Bus=0011 Vendor=0002 Product=0002 Version=0049 N: Name="PS2++ Logitech Mouse" P: Phys=isa0060/serio1/input0 H: Handlers=event1 ts0 mouse0 B: EV=7 B: KEY=f 0 0 0 0 B: REL=3 Using psmouse_noext=1 at boot time does not help. How comes that this doesn't work on the first run? I asked this more than a year ago, and somebody posted a fix, but obviously it wasn't accepted. What needs to be done to fix this? Harri- I was having problems with my psmouse also. Try the kernel boot option "usb-handoff", see if that helps. This is just a suggestion. I have nothing to do with the development of that driver. Good Luck. -- Michael Krufky - 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: s390 build fix.
On Sun, Aug 21, 2005 at 12:38:39AM -0400, Dave Jones wrote:
> {standard input}: Assembler messages:
> {standard input}:397: Error: symbol `.Litfits' is already defined
> {standard input}:585: Error: symbol `.Litfits' is already defined
>
> Newer gcc's inline this it seems, which blows up.
Eeek... Much easier (and already sent to Linus):
diff -urN RC13-rc6-git2-arm-float/arch/s390/kernel/cpcmd.c
RC13-rc6-git2-s390/arch/s390/kernel/cpcmd.c
--- RC13-rc6-git2-arm-float/arch/s390/kernel/cpcmd.c2005-08-10
10:37:46.0 -0400
+++ RC13-rc6-git2-s390/arch/s390/kernel/cpcmd.c 2005-08-10 20:38:56.0
-0400
@@ -46,9 +46,9 @@
"lra3,0(%4)\n"
"lr 5,%5\n"
"diag 2,4,0x8\n"
- "brc8, .Litfits\n"
+ "brc8, 1f\n"
"ar 5, %5\n"
- ".Litfits: \n"
+ "1: \n"
"lr %0,4\n"
"lr %1,5\n"
: "=d" (return_code), "=d" (return_len)
@@ -64,9 +64,9 @@
"sam31\n"
"diag 2,4,0x8\n"
"sam64\n"
- "brc8, .Litfits\n"
+ "brc8, 1f\n"
"agr5, %5\n"
- ".Litfits: \n"
+ "1: \n"
"lgr%0,4\n"
"lgr%1,5\n"
: "=d" (return_code), "=d" (return_len)
-
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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
On Sun, 21 Aug 2005 14:44, Michal Piotrowski wrote: > On 8/21/05, Con Kolivas <[EMAIL PROTECTED]> wrote: > > Well it will survive all right, but eventually get into swap thrash > > territory and that's not a meaningful cpu scheduler benchmark. > > > > Cheers, > > Con > > Ok. How about make -j? It's one of kernbench test runs, on my box load > average > 1500 ;). Just do that if you wish to overload the system. It's a vm benchmark. No doubt the cpu scheduler contributes to how the vm behaves, but it isn't a primary cpu scheduler test. > BTW I have only 1 gb ram, so high values of -j are road to hell for my > system... I'm still learning, but it's fun ;). Now I'll try your latest > -ck. Thanks for "1Gb Low Memory Support". You're welcome, Con - 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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
On 8/21/05, Con Kolivas <[EMAIL PROTECTED]> wrote: > Well it will survive all right, but eventually get into swap thrash territory > and that's not a meaningful cpu scheduler benchmark. > > Cheers, > Con > Ok. How about make -j? It's one of kernbench test runs, on my box load average > 1500 ;). BTW I have only 1 gb ram, so high values of -j are road to hell for my system... I'm still learning, but it's fun ;). Now I'll try your latest -ck. Thanks for "1Gb Low Memory Support". Regards, Michal Piotrowski - 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.5: psmouse mouse detection doesn't work
Hi folks, At boot time my Logitech mouse is detected as I: Bus=0011 Vendor=0002 Product=0001 Version= N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 H: Handlers=event1 ts0 mouse0 B: EV=7 B: KEY=7 0 0 0 0 B: REL=3 After manually reloading psmouse I get the expected I: Bus=0011 Vendor=0002 Product=0002 Version=0049 N: Name="PS2++ Logitech Mouse" P: Phys=isa0060/serio1/input0 H: Handlers=event1 ts0 mouse0 B: EV=7 B: KEY=f 0 0 0 0 B: REL=3 Using psmouse_noext=1 at boot time does not help. How comes that this doesn't work on the first run? I asked this more than a year ago, and somebody posted a fix, but obviously it wasn't accepted. What needs to be done to fix this? Regards Harri signature.asc Description: OpenPGP digital signature
s390 build fix.
{standard input}: Assembler messages:
{standard input}:397: Error: symbol `.Litfits' is already defined
{standard input}:585: Error: symbol `.Litfits' is already defined
Newer gcc's inline this it seems, which blows up.
--- linux-2.6.12/arch/s390/kernel/cpcmd.c~ 2005-08-18 15:12:51.0
-0400
+++ linux-2.6.12/arch/s390/kernel/cpcmd.c 2005-08-18 15:13:35.0
-0400
@@ -46,9 +46,9 @@ int __cpcmd(const char *cmd, char *resp
"lra3,0(%4)\n"
"lr 5,%5\n"
"diag 2,4,0x8\n"
- "brc8, .Litfits\n"
+ "brc8, .Litfits%=\n"
"ar 5, %5\n"
- ".Litfits: \n"
+ ".Litfits%=: \n"
"lr %0,4\n"
"lr %1,5\n"
: "=d" (return_code), "=d" (return_len)
@@ -64,9 +64,9 @@ int __cpcmd(const char *cmd, char *resp
"sam31\n"
"diag 2,4,0x8\n"
"sam64\n"
- "brc8, .Litfits\n"
+ "brc8, .Litfits%=\n"
"agr5, %5\n"
- ".Litfits: \n"
+ ".Litfits%=: \n"
"lgr%0,4\n"
"lgr%1,5\n"
: "=d" (return_code), "=d" (return_len)
-
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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
On Sun, 21 Aug 2005 14:16, Michal Piotrowski wrote: > Hi, > > On 8/21/05, Con Kolivas <[EMAIL PROTECTED]> wrote: > > On Sun, 21 Aug 2005 11:34, Michal Piotrowski wrote: > > > Hi, > > > > Hi > > > > > here are kernbench results: > > > > Nice to see you using kernbench :) > > > > > ./kernbench -M -o 128 > > > [..] > > > Average Optimal -j 128 Load Run: > > > > Was there any reason you chose 128? Optimal usually works out > > automatically from kernbench to 4x number_cpus. If I recall correctly you > > have 4 cpus? Not sure what 128 represents. > > > > Cheers, > > Con > > No, I just have 1 pentium 4 with ht ;). > > Why I chose 128? I just want very high loads. Now I'll try -j192 and > -j256, but I don't know how does my system survive it. Well it will survive all right, but eventually get into swap thrash territory and that's not a meaningful cpu scheduler benchmark. Cheers, Con - 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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
Hi, On 8/21/05, Con Kolivas <[EMAIL PROTECTED]> wrote: > On Sun, 21 Aug 2005 11:34, Michal Piotrowski wrote: > > Hi, > > Hi > > > here are kernbench results: > > Nice to see you using kernbench :) > > > ./kernbench -M -o 128 > > [..] > > Average Optimal -j 128 Load Run: > > Was there any reason you chose 128? Optimal usually works out automatically > from kernbench to 4x number_cpus. If I recall correctly you have 4 cpus? Not > sure what 128 represents. > > Cheers, > Con > No, I just have 1 pentium 4 with ht ;). Why I chose 128? I just want very high loads. Now I'll try -j192 and -j256, but I don't know how does my system survive it. Regards, Michal Piotrowski - 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-usb-devel] Re: Problems with connect/disconnect cycles
On Sam, 20 Aug 2005, Alan Stern wrote: > Speaking in broad terms, it's normal to see new device connection and > configuration messages like the ones above when a USB device is plugged in > to your computer. What's not normal is to see disconnects. So you should Mind that this is an *internal* builtin card reader on my laptop. I will go through the log files and look if I find patterns. > why is the card reader disconnecting? Turning on CONFIG_USB_DEBUG may ok. Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- AASLEAGH (n.) A liqueur made only for drinking at the end of a revoltingly long bottle party when all the drinkable drink has been drunk. --- Douglas Adams, The Meaning of Liff - 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: largefile-support-for-accounting.patch added to -mm tree
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote: > Another annoying problem is that once the system reaches this 2GB > limit, then every process which exits will receive a signal, > SIGXFSZ. This signal is generated because an attempt was made to > write beyond the limit for the file descriptor. This signal makes > it look like every process has exited due to a signal, when in fact, > they have not. Eeek. > The solution is to add the O_LARGEFILE flag to the list of flags > used to open the accounting file. The rest of the accounting > support is already largefile safe. That fixes the larger accounting file problem but it doesn't address the fact that signals resulting writes to the accounting file are delivered incorrectly. We could still have issues if the accounting file as over quota for example. Surely all accounting file writes should be insulated from the processes involved? - 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-usb-devel] Re: Problems with connect/disconnect cycles
On Sun, 21 Aug 2005, Norbert Preining wrote: > Hi USB developers, hi Andrew! > > On Mon, 21 Mär 2005, preining wrote: > > Dear usb developers, dear Andrew! > > > > I found that my builtin sd card reader connected via USB port > > experiences several connect/reconnect cycles every time I boot. > > > > I am using 2.6.11-mm4. > > Same now with 2.6.13-rc6-mm1. This time it got really bad: > > Aug 20 14:00:19 gandalf vmunix: usb 2-2: USB disconnect, address 2 > Aug 20 14:00:19 gandalf kernel: usb 2-2: new full speed USB device using > uhci_hcd and address 3 > Aug 20 14:00:19 gandalf kernel: scsi1 : SCSI emulation for USB Mass Storage > devices > Aug 20 14:00:19 gandalf kernel: usb-storage: device found at 3 > Aug 20 14:00:19 gandalf kernel: usb-storage: waiting for device to settle > before scanning > Aug 20 14:00:21 gandalf usb.agent[6109]: usb-storage: already loaded > Aug 20 14:00:24 gandalf vmunix: Vendor: Generic Model: Flash R/W > Rev: 2002 > Aug 20 14:00:24 gandalf vmunix: Type: Direct-Access > ANSI SCSI revision: 02 > Aug 20 14:00:24 gandalf vmunix: Attached scsi removable disk sda at scsi1, > channel 0, id 0, lun 0 > Aug 20 14:00:24 gandalf kernel: usb-storage: device scan complete > Aug 20 14:00:26 gandalf scsi.agent[6154]: sd_mod: loaded successfully > (for disk) > Unfortunately I cannot in any way track down this problem to specific > kernels, or specific work situations. It sometimes happens, sometimes > not. > > If anyone has any idea how to debug such a stupid problem, I would be > glad. Speaking in broad terms, it's normal to see new device connection and configuration messages like the ones above when a USB device is plugged in to your computer. What's not normal is to see disconnects. So you should be concentrating on what happens just before the log entries you posted -- why is the card reader disconnecting? Turning on CONFIG_USB_DEBUG may provide more help. Alan Stern - 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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
On Sun, 21 Aug 2005 11:34, Michal Piotrowski wrote: > Hi, Hi > here are kernbench results: Nice to see you using kernbench :) > ./kernbench -M -o 128 > [..] > Average Optimal -j 128 Load Run: Was there any reason you chose 128? Optimal usually works out automatically from kernbench to 4x number_cpus. If I recall correctly you have 4 cpus? Not sure what 128 represents. Cheers, Con - 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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
[1.] One line summary of the problem: oops when shuting down system [2.] Full description of the problem/report: After kernbenching nicksched (heav load make -j128) I just record results on cd and shutdown system. [3.] Keywords (i.e., modules, networking, kernel): plugsched, nicksched, sysfs, vfs [4.] Kernel version (from /proc/version): Linux version 2.6.13-rc6-2 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #14 SMP Mon Aug 15 08:50:46 CEST 2005 [5.] Output of Oops Aug 21 03:21:32 ng02 shutdown[9216]: shutting down for system halt Aug 21 03:21:33 ng02 kernel: c0003eac Aug 21 03:21:33 ng02 kernel: PREEMPT SMP Aug 21 03:21:33 ng02 kernel: Modules linked in: nls_iso8859_1 isofs nls_base zliAug 21 03:21:33 ng02 kernel: CPU:0 Aug 21 03:21:33 ng02 kernel: EIP:0060:[]Not tainted VLI Aug 21 03:21:33 ng02 kernel: EFLAGS: 00010246 (2.6.13-rc6-2) Aug 21 03:21:33 ng02 kernel: EIP is at 0xc0003eac Aug 21 03:21:33 ng02 kernel: eax: e668b000 ebx: f7cec680 ecx: edxAug 21 03:21:33 ng02 kernel: esi: f7cec688 edi: c036dd04 ebp: ca8f5440 espAug 21 03:21:33 ng02 kernel: ds: 007b es: 007b ss: 0068 Aug 21 03:21:33 ng02 kernel: Process udev (pid: 9771, threadinfo=cfa39000 task=fAug 21 03:21:33 ng02 kernel: Stack: c02386f2 f7cec680 e668b000 f6cfb0c0 c01a8fedAug 21 03:21:33 ng02 kernel: f6cfb0c0 f744e980 080c6f48 Aug 21 03:21:33 ng02 kernel:f744e980 080c6f48 1000 c016e629 f744e980Aug 21 03:21:33 ng02 kernel: Call Trace: Aug 21 03:21:33 ng02 kernel: [] class_device_attr_show+0x32/0x40 Aug 21 03:21:33 ng02 kernel: [] fill_read_buffer+0x5d/0xa0 Aug 21 03:21:33 ng02 kernel: [] sysfs_read_file+0x31/0x70 Aug 21 03:21:33 ng02 kernel: [] vfs_read+0xe9/0x1b0 Aug 21 03:21:33 ng02 kernel: [] sys_read+0x51/0x80 Aug 21 03:21:33 ng02 kernel: [] syscall_call+0x7/0xb Aug 21 03:21:33 ng02 kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Aug 21 03:21:37 ng02 kernel: Kernel logging (proc) stopped. [7.] Environment [7.1.] Software If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ng02.pl 2.6.13-rc6-2 #14 SMP Mon Aug 15 08:50:46 CEST 2005 i686 GNU/Linux Gnu C 3.3.5 Gnu make 3.80 binutils 2.15 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre1 e2fsprogs 1.37 reiserfsprogs line reiser4progs line PPP2.4.3 nfs-utils 1.0.6 Linux C Library2.3.2 Dynamic linker (ldd) 2.3.2 Linux C++ Library 6.0.4 Procps 3.2.1 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 udev 056 Modules Loaded md5 ipv6 af_packet snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc hw_random ehci_hcd uhci_hcd usbcore sk98lin i2c_isa i2c_i801 i2c_core ide_cd cdrom unix [8.] Config file # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc6 # Mon Aug 15 08:41:41 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-2" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_PLUGSCHED=y CONFIG_CPUSCHED_DEFAULT_INGO=y # CONFIG_CPUSCHED_DEFAULT_STAIRCASE is not set # CONFIG_CPUSCHED_DEFAULT_SPA_NF is not set # CONFIG_CPUSCHED_DEFAULT_ZAPHOD is not set # CONFIG_CPUSCHED_DEFAULT_NICK is not set # CONFIG_EMBEDDED is not set CONFIG_CPUSCHED_INGO=y CONFIG_CPUSCHED_STAIRCASE=y CONFIG_CPUSCHED_SPA=y CONFIG_CPUSCHED_SPA_NF=y CONFIG_CPUSCHED_ZAPHOD=y CONFIG_CPUSCHED_NICK=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set #
Re: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
Hi, here are kernbench results: cpusched=ingosched ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 365,4 User Time 620,8 System Time 64,6 Percent CPU 187,2 Context Switches 38296,8 Sleeps 37867 (reboot) --- cpusched=staircase ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 611,6 User Time 616,4 System Time 81 Percent CPU 114,8 Context Switches 96470,2 Sleeps 122413 (reboot) --- sched_compute=1 ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 354,6 User Time 615,2 System Time 61 Percent CPU 190 Context Switches 9876,4 Sleeps 18510,4 (reboot) --- cpusched=spa_no_frills ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 352 User Time 624 System Time 60 Percent CPU 193,8 Context Switches 19185,4 Sleeps 18205,8 (reboot) --- cpusched=zaphod max_ia_bonus=default max_tpt_bonus=default ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 389,4 User Time 607,8 System Time 58,8 Percent CPU 170,8 Context Switches 44965,2 Sleeps 27352,8 (reboot) --- max_ia_bonus=0 max_tpt_bonus=default ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 351,4 User Time 623,4 System Time 59,8 Percent CPU 194 Context Switches 21264,6 Sleeps 20284,6 (reboot) --- max_ia_bonus=default max_tpt_bonus=0 ./kernbench -M -o 128 [..] Elapsed Time 387,6 User Time 608 System Time 57,6 Percent CPU 171,6 Context Switches 43684,8 Sleeps 26757,4 (reboot) --- max_ia_bonus=0 max_tpt_bonus=0 ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 351 User Time 623,4 System Time 60,4 Percent CPU 194,2 Context Switches 21241,8 Sleeps 19751,6 (reboot) --- cpusched=nicksched ./kernbench -M -o 128 [..] Average Optimal -j 128 Load Run: Elapsed Time 776,4 User Time 590,8 System Time 85,4 Percent CPU 95,4 Context Switches 99664,8 Sleeps 147169 Regards, Michal Piotrowski - 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: Problems with connect/disconnect cycles
Hi USB developers, hi Andrew! On Mon, 21 Mär 2005, preining wrote: > Dear usb developers, dear Andrew! > > I found that my builtin sd card reader connected via USB port > experiences several connect/reconnect cycles every time I boot. > > I am using 2.6.11-mm4. Same now with 2.6.13-rc6-mm1. This time it got really bad: Aug 20 14:00:19 gandalf vmunix: usb 2-2: USB disconnect, address 2 Aug 20 14:00:19 gandalf kernel: usb 2-2: new full speed USB device using uhci_hcd and address 3 Aug 20 14:00:19 gandalf kernel: scsi1 : SCSI emulation for USB Mass Storage devices Aug 20 14:00:19 gandalf kernel: usb-storage: device found at 3 Aug 20 14:00:19 gandalf kernel: usb-storage: waiting for device to settle before scanning Aug 20 14:00:21 gandalf usb.agent[6109]: usb-storage: already loaded Aug 20 14:00:24 gandalf vmunix: Vendor: Generic Model: Flash R/W Rev: 2002 Aug 20 14:00:24 gandalf vmunix: Type: Direct-Access ANSI SCSI revision: 02 Aug 20 14:00:24 gandalf vmunix: Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Aug 20 14:00:24 gandalf kernel: usb-storage: device scan complete Aug 20 14:00:26 gandalf scsi.agent[6154]: sd_mod: loaded successfully (for disk) Aug 21 01:55:44 gandalf vmunix: usb 2-2: USB disconnect, address 32 Aug 21 01:55:44 gandalf kernel: usb 2-2: new full speed USB device using uhci_hcd and address 33 Aug 21 01:55:44 gandalf kernel: scsi32 : SCSI emulation for USB Mass Storage devices Aug 21 01:55:44 gandalf kernel: usb-storage: device found at 33 Aug 21 01:55:44 gandalf kernel: usb-storage: waiting for device to settle before scanning Aug 21 01:55:47 gandalf usb.agent[17503]: usb-storage: already loaded Aug 21 01:55:49 gandalf vmunix: Vendor: Generic Model: Flash R/W Rev: 2002 Aug 21 01:55:49 gandalf vmunix: Type: Direct-Access ANSI SCSI revision: 02 Aug 21 01:55:49 gandalf kernel: Attached scsi removable disk sda at scsi32, channel 0, id 0, lun 0 Aug 21 01:55:49 gandalf vmunix: usb-storage: device scan complete Aug 21 01:55:50 gandalf scsi.agent[17544]: sd_mod: loaded successfully (for disk) uuu, now many of these Aug 21 02:09:18 gandalf vmunix: ACPI-0131: *** Error: Invalid owner_id: 00 and many many more of these: Aug 21 03:07:19 gandalf vmunix: ACPI-0096: *** Error: Could not allocate new owner_id (32 max), AE_OWNER_ID_LIMIT Unfortunately I cannot in any way track down this problem to specific kernels, or specific work situations. It sometimes happens, sometimes not. If anyone has any idea how to debug such a stupid problem, I would be glad. Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HUCKNALL (vb.) To crouch upwards: as in the movement of a seated person's feet and legs made in order to allow a cleaner's hoover to pass beneath them. --- Douglas Adams, The Meaning of Liff - 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: sched_yield() makes OpenLDAP slow
Howard Chu wrote: I'll note that we removed a number of the yield calls (that were in OpenLDAP 2.2) for the 2.3 release, because I found that they were redundant and causing unnecessary delays. My own test system is running on a Linux 2.6.12.3 kernel (installed over a SuSE 9.2 x86_64 distro), and OpenLDAP 2.3 runs perfectly well here, now that those redundant calls have been removed. But I also found that I needed to add a new yield(), to work around yet another unexpected issue on this system - we have a number of threads waiting on a condition variable, and the thread holding the mutex signals the var, unlocks the mutex, and then immediately relocks it. The expectation here is that upon unlocking the mutex, the calling thread would block while some waiting thread (that just got signaled) would get to run. In fact what happened is that the calling thread unlocked and relocked the mutex without allowing any of the waiting threads to run. In this case the only solution was to insert a yield() after the mutex_unlock(). So again, for those of you claiming "oh, all you need to do is use a condition variable or any of the other POSIX synchronization primitives" - yes, that's a nice theory, but reality says otherwise. I encountered a similar issue with some software that I wrote, and used a similar workaround, however this was basically because there wasn't enough time available at the time to redesign things to work properly. The problem here is essentially caused by the fact that the mutex is being locked for an excessively large proportion of the time and not letting other threads in. In the case I am thinking of, posting the messages to the thread that was hogging the mutex via a signaling queue would have been a better solution than using yield and having correct operation depend on undefined parts of thread scheduling behavior.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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 2.6.13-rc6 1/2] New Syscall: get rlimits of any process
Wieland Gmeiner <[EMAIL PROTECTED]> wrote:
>
> +asmlinkage long sys_getprlimit(pid_t pid, unsigned int resource, struct
> rlimit __user *rlim)
> +{
> +struct rlimit value;
> +task_t *p;
> +int retval = -EINVAL;
> +
> +if (resource >= RLIM_NLIMITS)
> +goto out_nounlock;
> +
> +if (pid < 0)
> +goto out_nounlock;
> +
> +retval = -ESRCH;
> +if (pid == 0) {
> +p = current;
> +} else {
> +read_lock(&tasklist_lock);
> +p = find_task_by_pid(pid);
> +}
> +if (p) {
> +retval = -EPERM;
> +if ((current->euid ^ p->suid) && (current->euid ^ p->uid) &&
> +(current->uid ^ p->suid) && (current->uid ^ p->uid) &&
> +!capable(CAP_SYS_RESOURCE))
> +goto out_unlock;
> +
> +task_lock(p->group_leader);
> +value = p->signal->rlim[resource];
> +task_unlock(p->group_leader);
There isn't much point in taking task_lock() here. The value can change
after the lock has been dropped anyway.
> +retval = copy_to_user(rlim, &value, sizeof(*rlim)) ?
> -EFAULT : 0;
It's not legal to perform copy_*_user() (which sleeps) inside read_lock(),
write_lock(), spin_lock(), preempt_diable() or, really,
local_irq_disable().
> +}
> +if (pid == 0)
> +goto out_nounlock;
> +
> +out_unlock:
> +read_unlock(&tasklist_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/
Re: [OT]Linus trademarks Linux?!!
Gaah. I don't tend to bother about slashdot, because quite frankly, the
whole _point_ of slashdot is to have this big public wanking session with
people getting together and making their own "insightful" comment on any
random topic, whether they know anything about it or not.
[ And don't get me wrong - I follow slashdot too, exactly because it's fun
to see people argue. I'm not complaining ;]
And I don't tend to worry about the Inquirer and the Register, because
both of them are all about being rough and saying things in ways that
might not be acceptable in other places, and that's what makes them fun to
read. So when they then write something nasty about Linux (or me), hey, it
goes with the territory.
But I was really hoping this particular wanking session wouldn't overflow
into Linux-kernel.
Anyway, the posting Jesper points to is a fine one. Partly to show that
this trademark thing sure as hell isn't anything new, and partly because
the rules really haven't changed.
So let's repeat that link again, just as background,
http://boudicca.tux.org/hypermail/linux-kernel/2000week04/0654.html
and then people should think a bit (and maybe research) what a trademark
really means.
A trademark exists to set up some rules about using a "mark" (name, logo,
you name it) in trade. The people who pay to license (or get a unique
trademark of their own) a certain name do so because they care about that
particular name. People who don't care, don't pay. It's really that easy.
It's about getting legal protection for a particular name.
For example, this means that a _user_ would never pay a single cent over a
trademark. I don't know why/how the Inq even came to that "companies to
pay for using free software" idea. It shows a total lack of understanding
about what a trademark is in the first place.
Now, a company that has a company name usually _does_ want to protect
their name. Not always, but it's kind of embarrassing (and easily an
expensive and big bother) if somebody else trademarks that name, and then
sends a cease-and-desist order to you and forces you to switch to
something else.
So you'll find that most commerical entities protect their name some way,
regardless of _what_ that name is. For example, let's say that you called
your company or distribution "Lipro", then you'd like to trademark that.
Goodie. It's pretty expensive, but most companies feel that it's more than
worth it to know that you've got exclusive rights to that name, and nobody
else can force you to change,
So the first point here is that regardless of you call your Linux
distribution "Linux Something" or something totally different, you'll want
to protect that name if you are serious about making a big commercial
distribution. Exactly because you do _not_ want to be in the situation
that somebody else hijacks your name from you.
Now, you can do that protection two different ways: you can make up a
unique name of your own ("Red Hat" or "Linspire" or "Debian" or whatever),
and trademark that. Then the trademark office keeps track of things, and
guarantees that there are no clashes (within your business area).
Or, alternatively, you can ask somebody else who already has a unique name
if they might "sublicense" their name in combination with something else.
In the case of "Linux", that name is already guaranteed unique by the
trademark office, so let's say that you felt that you wanted to have a
unique name that contained that, you'd approach LMI and say "I want to
call my magazine LinuxJournal, can you write up paperwork that makes sure
that nobody else can do so"?
And let's repeat: somebody who doesn't want to _protect_ that name would
never do this. You can call anything "MyLinux", but the downside is that
you may have somebody else who _did_ protect himself come along and send
you a cease-and-desist letter. Or, if the name ends up showing up in a
trademark search that LMI needs to do every once in a while just to
protect the trademark (another legal requirement for trademarks), LMI
itself might have to send you a cease-and-desist-or-sublicense it letter.
At which point you either rename it to something else, or you sublicense
it. See? It's all about whether _you_ need the protection or not, not
about whether LMI wants the money or not.
As to the "cease-and-desist or sublicense the mark" letters, they are
sadly directly brought on by the requirements of maintaining a trademark.
If you have a trademark, you have to police it, which means that you have
to do trademark searches to see who uses it in a commercial setting, and
make sure that they use it properly.
So to answer a particular question that came up here on Linux-kernel:
"Does the linuxjournal.com pay $5000?".
First off, I don't know where the $5000 came from - it's different for
different classes of people. Secondly, LinuxJournal was one of the
companies that raised the money to get the "Linux" trademark in the first
place! As
[PATHC] remove a redundant variable in sys_prctl()
Here's a re-send of a small patch I sent on Aug. 9.
The patch removes a redundant variable `sig' from sys_prctl().
For some reason, when sys_prctl is called with option == PR_SET_PDEATHSIG
then the value of arg2 is assigned to an int variable named sig. Then sig
is tested with valid_signal() and later used to set the value of
current->pdeath_signal .
There is no reason to use this intermediate variable since valid_signal()
takes a unsigned long argument, so it can handle being passed arg2 directly,
and if the call to valid_signal is OK, then we know the value of arg2 is in
the range zero to _NSIG and thus it'll easily fit in a plain int and thus
there's no problem assigning it later to current->pdeath_signal (which is
an int).
The patch gets rid of the pointless variable `sig'.
This reduces the size of kernel/sys.o in 2.6.13-rc6-mm1 by 32 bytes on my
system.
Patch has been compile tested, boot tested, and just to make damn sure I
didn't break anything I wrote a quick test app that calls
prctl(PR_SET_PDEATHSIG ...) with the entire range of values for a
unsigned long, and it behaves as expected with and without the patch.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
kernel/sys.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
--- linux-2.6.13-rc6-mm1-orig/kernel/sys.c 2005-08-19 19:21:25.0
+0200
+++ linux-2.6.13-rc6-mm1/kernel/sys.c 2005-08-21 01:30:03.0 +0200
@@ -1709,7 +1709,6 @@ asmlinkage long sys_prctl(int option, un
unsigned long arg4, unsigned long arg5)
{
long error;
- int sig;
error = security_task_prctl(option, arg2, arg3, arg4, arg5);
if (error)
@@ -1717,12 +1716,11 @@ asmlinkage long sys_prctl(int option, un
switch (option) {
case PR_SET_PDEATHSIG:
- sig = arg2;
- if (!valid_signal(sig)) {
+ if (!valid_signal(arg2)) {
error = -EINVAL;
break;
}
- current->pdeath_signal = sig;
+ current->pdeath_signal = arg2;
break;
case PR_GET_PDEATHSIG:
error = put_user(current->pdeath_signal, (int __user
*)arg2);
-
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: sched_yield() makes OpenLDAP slow
Howard Chu wrote: Lee Revell wrote: On Sat, 2005-08-20 at 11:38 -0700, Howard Chu wrote: > But I also found that I needed to add a new yield(), to work around > yet another unexpected issue on this system - we have a number of > threads waiting on a condition variable, and the thread holding the > mutex signals the var, unlocks the mutex, and then immediately > relocks it. The expectation here is that upon unlocking the mutex, > the calling thread would block while some waiting thread (that just > got signaled) would get to run. In fact what happened is that the > calling thread unlocked and relocked the mutex without allowing any > of the waiting threads to run. In this case the only solution was > to insert a yield() after the mutex_unlock(). That's exactly the behavior I would expect. Why would you expect unlocking a mutex to cause a reschedule, if the calling thread still has timeslice left? That's beside the point. Folks are making an assertion that sched_yield() is meaningless; this example demonstrates that there are cases where sched_yield() is essential. The point is, with SCHED_OTHER scheduling, sched_yield() need not do anything. It may not let any other tasks run. The fact that it does on Linux is because we do attempt to do something expected... but the simple matter is that you can't realy on it to do what you expect. I'm not sure exactly how you would solve the above problem, but I'm sure it can be achieved using mutexes (for example, you could have a queue where every thread waits on its own private mutex) but I don't do much userspace C programming sorry. Send instant messages to your online friends http://au.messenger.yahoo.com - 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: RTL8139, the final patch ?
Nick Warne <[EMAIL PROTECTED]> writes:
> On Saturday 20 August 2005 21:53, you wrote:
>> I have a problem with it:
>> It's about patching, reverting, patching, reverting,...
>> I got lost. That's why I asked for a... "straighter" one :-)
>
>>> But I looked at what he said and found the real problem on my system (after
>>> all that):
>>> http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html
>
>> It's about a configuration option in the kernel?
>> The patch is about adding the option, if i'm right.
>
> No, what happened was on 2.6.2 all was well. When 2.6.3 came out I got these
> timeout errors on the NIC's - but using the 2.6.2 8139too.c file in 2.6.3
> worked. Mr Hirofumi then took up the challenge and sent me patches. Slowly
> he resolved the issue, but the conclusion was it wasn't the code causing it.
>
> It was an option in my BIOS PCI level/edge settings as I posted. People on
> laptops get this error, like you, but there is no BIOS option as such... :-/
Yes. Thanks Nick.
Rakotomandimby, can you try attached patch?
It would solve the problem, if the cause is level/edge trigger.
(Actually, patch is just hideing the problem.)
And please send dmesg, lspci -vvvxxx, cat /proc/interrupts, 8259A.pl, mptable.
In some cases, we may be able to add workaround. But we need to find
the cause of problem before it.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
Disable 8139too NAPI for testing the Leval-Edge trigger problem
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
drivers/net/8139too.c | 37 ++---
1 files changed, 30 insertions(+), 7 deletions(-)
diff -puN drivers/net/8139too.c~8139too-napi-revert drivers/net/8139too.c
--- linux-2.6.13-rc6/drivers/net/8139too.c~8139too-napi-revert 2005-08-16 03:42:13.0 +0900
+++ linux-2.6.13-rc6-hirofumi/drivers/net/8139too.c 2005-08-16 03:52:15.0 +0900
@@ -112,7 +112,7 @@
#include
#include
-#define RTL8139_DRIVER_NAME DRV_NAME " Fast Ethernet driver " DRV_VERSION
+#define RTL8139_DRIVER_NAME DRV_NAME " Fast Ethernet driver (Disable NAPI) " DRV_VERSION
#define PFX DRV_NAME ": "
/* Default Message level */
@@ -120,6 +120,7 @@
NETIF_MSG_PROBE | \
NETIF_MSG_LINK)
+//#define ENABLE_NAPI
/* enable PIO instead of MMIO, if CONFIG_8139TOO_PIO is selected */
#ifdef CONFIG_8139TOO_PIO
@@ -624,7 +625,9 @@ static void rtl8139_tx_timeout (struct n
static void rtl8139_init_ring (struct net_device *dev);
static int rtl8139_start_xmit (struct sk_buff *skb,
struct net_device *dev);
+#ifdef ENABLE_NAPI
static int rtl8139_poll(struct net_device *dev, int *budget);
+#endif
#ifdef CONFIG_NET_POLL_CONTROLLER
static void rtl8139_poll_controller(struct net_device *dev);
#endif
@@ -974,8 +977,10 @@ static int __devinit rtl8139_init_one (s
/* The Rtl8139-specific entries in the device structure. */
dev->open = rtl8139_open;
dev->hard_start_xmit = rtl8139_start_xmit;
+#ifdef ENABLE_NAPI
dev->poll = rtl8139_poll;
dev->weight = 64;
+#endif
dev->stop = rtl8139_close;
dev->get_stats = rtl8139_get_stats;
dev->set_multicast_list = rtl8139_set_rx_mode;
@@ -2024,8 +2029,11 @@ no_early_rx:
dev->last_rx = jiffies;
tp->stats.rx_bytes += pkt_size;
tp->stats.rx_packets++;
-
+#ifdef ENABLE_NAPI
netif_receive_skb (skb);
+#else
+ netif_rx (skb);
+#endif
} else {
if (net_ratelimit())
printk (KERN_WARNING
@@ -2103,7 +2111,7 @@ static void rtl8139_weird_interrupt (str
dev->name, pci_cmd_status);
}
}
-
+#ifdef ENABLE_NAPI
static int rtl8139_poll(struct net_device *dev, int *budget)
{
struct rtl8139_private *tp = netdev_priv(dev);
@@ -2137,7 +2145,7 @@ static int rtl8139_poll(struct net_devic
return !done;
}
-
+#endif /* !ENABLE_NAPI */
/* The interrupt handler does all of the Rx thread work and cleans up
after the Tx thread. */
static irqreturn_t rtl8139_interrupt (int irq, void *dev_instance,
@@ -2149,8 +2157,14 @@ static irqreturn_t rtl8139_interrupt (in
u16 status, ackstat;
int link_changed = 0; /* avoid bogus "uninit" warning */
int handled = 0;
+#ifndef ENABLE_NAPI
+ int boguscnt = 20;
+#endif
spin_lock (&tp->lock);
+#ifndef ENABLE_NAPI
+retry:
+#endif
status = RTL_R16 (IntrStatus);
/* shared irq? */
@@ -2162,13 +2176,13 @@ static irqreturn_t rtl8139_interrupt (in
/* h/w no longer present (hotplug?) or major error, bail */
if (unlikely(status == 0x))
goto out;
-
+#ifdef ENABLE_NAPI
/* close possible race's with dev_close */
if (unlikely(!netif_running(dev))) {
RTL_W16 (IntrMask, 0);
goto out;
}
-
+#endif
/* Acknowledge all of the current interrupt sources ASAP, but
an first get an additional status bit from CSCR. */
if (unlikely(status & RxUnderrun))
@@ -2178,6 +2192,7 @@ static irqreturn_t rtl8139_interrupt (in
if (ackstat)
RTL_W16 (IntrStatus, ackstat);
+#ifdef ENABLE_NAPI
/* Receive packets are processed by pol
Re: [-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sat, 20 Aug 2005 21:03:09 +0200 > This breaks the compilation with CONFIG_PROC_FS=n: .. > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. - 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/RFT 4/5] CLOCK-Pro page replacement
Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-19 at 00:10 -0700, Andrew Morton wrote:
> > Rusty Russell <[EMAIL PROTECTED]> wrote:
> > > I believe we just ignored sparc64. That usually works for solving these
> > > kind of bugs. 8)
> >
> > heh. iirc, it was demonstrable on x86 also.
>
> No. gcc-2.95 on Sparc64 put uninititialized vars into the bss, ignoring
> the __attribute__((section(".data.percpu"))) directive. x86 certainly
> doesn't have this, I just tested it w/2.95.
>
> Really, it's Sparc64 + gcc-2.95. Send an urgent telegram to the user
> telling them to upgrade.
I recently asked if gcc-2.95 was really still supported, and was told that
it is in common use for its speed...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
-
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 0/5] improve i2c probing
Interestingly (we for me at least ;-) I have been working on an SPI subsystem that was/is a copy of the I2C subsystem with changes as SPI doesnt have a protocol like I2C. I am at the stage of tidying up the structures in the head files and looking at where they are used in the core layer. To me, what I have, like I2C, doesnt tie in very well with the new driver model (although Im not overly familiar with it, I think I finally understand platform devices :-). The current I2C core layer seems to be only registering a bus type and devices so you can see them in sysfs as none of the functions seem to do anything. I wonder how much work the new kernel subsystems can do for us to cut down the size of i2c-core (and thus also spi-core). I guess there is no escaping the fact that Im going to gave to do some more homework and study the code. Any thoughts or insights would be very welcome. Mark --- David Brownell <[EMAIL PROTECTED]> wrote: > Hmm, some of this resembles my prototype from last > month: > > > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013012.html > > Both ended up with new driver probe() methods > attaching to *devices* not > to busses, and used the probe signature the i2c core > already handles. > That helps eliminate one of the surprises hitting > anyone starting to use > the I2C driver stack. But not the more fundamental > one... > > What would you think about actually making I2C > probing work more like > standard driver model probing, instead? That is, > have the probe method > signature look like this: > > int probe(struct i2c_client *dev, void > *driver_data) > > In normal driver model usage, infrastructure creates > the devices, and the > device drivers just bind to them. But I2C doesn't > support that even for > the submodel where it's very appropriate: devices > that have been probed, > or which (as with platform_bus) were explicitly > declared to exist. > > I2C drivers would either continue the old school way > ... or could start > acting more like they do in other mainstream Linux > driver frameworks. > > - Dave > > > - > 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 help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - 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-rc6] dcdbas: add Dell Systems Management Base Driver with sysfs support
This patch adds the Dell Systems Management Base Driver with sysfs support. This patch incorporates changes based on comments from the previous posting. Summary of changes: * Changed permissions on sysfs files so that only owner can read. * Changed to use __uNN/__sNN types in structs. * smi_data_write will grow smi_data_buf if needed. * Renamed struct callintf_cmd to struct smi_cmd. * Renamed callintf_smi to smi_request. * Added 2 more supported values that were requested in smi_request_store. * Hold rtc_lock across SMI in host_control_smi. Signed-off-by: Doug Warzecha <[EMAIL PROTECTED]> --- diff -uprN linux-2.6.13-rc6.orig/Documentation/dcdbas.txt linux-2.6.13-rc6/Documentation/dcdbas.txt --- linux-2.6.13-rc6.orig/Documentation/dcdbas.txt 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.13-rc6/Documentation/dcdbas.txt 2005-08-19 18:45:37.0 -0500 @@ -0,0 +1,87 @@ +Overview + +The Dell Systems Management Base Driver provides a sysfs interface for +systems management software such as Dell OpenManage to perform system +management interrupts and host control actions (system power cycle or +power off after OS shutdown) on certain Dell systems. + +Dell OpenManage requires this driver on the following Dell PowerEdge systems: +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, +700, and 750. Other Dell software such as the open source Libsmbios library +is expected to make use of this driver, and it may include the use of this +driver on other Dell systems. + + +System Management Interrupt + +On some Dell systems, systems management software must access certain +management information via a system management interrupt (SMI). The SMI data +buffer must reside in 32-bit address space, and the physical address of the +buffer is required for the SMI. The driver maintains the memory required for +the SMI and provides a way for the application to generate the SMI. +The driver creates the following sysfs entries for systems management +software to perform these system management interrupts: + +/sys/devices/platform/dcdbas/smi_data +/sys/devices/platform/dcdbas/smi_data_buf_phys_addr +/sys/devices/platform/dcdbas/smi_data_buf_size +/sys/devices/platform/dcdbas/smi_request + +Systems management software must perform the following steps to execute +a SMI using this driver: + +1) Lock smi_data. +2) Write system management command to smi_data. +3) Write "1" to smi_request to generate a calling interface SMI or + "2" to generate a raw SMI. +4) Read system management command response from smi_data. +5) Unlock smi_data. + + +Host Control Action + +Dell OpenManage supports a host control feature that allows the administrator +to perform a power cycle or power off of the system after the OS has finished +shutting down. On some Dell systems, this host control feature requires that +a driver perform a SMI after the OS has finished shutting down. + +The driver creates the following sysfs entries for systems management software +to schedule the driver to perform a power cycle or power off host control +action after the system has finished shutting down: + +/sys/devices/platform/dcdbas/host_control_action +/sys/devices/platform/dcdbas/host_control_smi_type +/sys/devices/platform/dcdbas/host_control_on_shutdown + +Dell OpenManage performs the following steps to execute a power cycle or +power off host control action using this driver: + +1) Write host control action to be performed to host_control_action. +2) Write type of SMI that driver needs to perform to host_control_smi_type. +3) Write "1" to host_control_on_shutdown to enable host control action. +4) Initiate OS shutdown. + (Driver will perform host control SMI when it is notified that the OS + has finished shutting down.) + + +Host Control SMI Type + +The following table shows the value to write to host_control_smi_type to +perform a power cycle or power off host control action: + +PowerEdge SystemHost Control SMI Type +- + 300 HC_SMITYPE_TYPE1 + 1300 HC_SMITYPE_TYPE1 + 1400 HC_SMITYPE_TYPE2 + 500SC HC_SMITYPE_TYPE2 + 1500SC HC_SMITYPE_TYPE2 + 1550 HC_SMITYPE_TYPE2 + 600SC HC_SMITYPE_TYPE2 + 1600SC HC_SMITYPE_TYPE2 + 650 HC_SMITYPE_TYPE2 + 1655MC HC_SMITYPE_TYPE2 + 700 HC_SMITYPE_TYPE3 + 750 HC_SMITYPE_TYPE3 + + diff -uprN linux-2.6.13-rc6.orig/drivers/firmware/dcdbas.c linux-2.6.13-rc6/drivers/firmware/dcdbas.c --- linux-2.6.13-rc6.orig/drivers/firmware/dcdbas.c 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.13-rc6/drivers/firmware/dcdbas.c 2005-08-19 19:07:50.823719952 -0500 @@ -0,0 +1,593 @@ +/* + * dcdbas.c: Dell Systems Management Base Driver + * + * The Dell Systems Management Base Driver provides a sysfs interface for + * systems management software to perform System Managemen
Re: 2.6.13-rc6-rt9
On Sat, Aug 20, 2005 at 09:27:25PM +0200, Peter Zijlstra wrote: > Jeff, could you help us out here? > What exactly does uml need to get out of the calibrate delay loop? Interrupts, it's not too demanding :-) If it's not seeing VTALRM, then it will never leave the calibration loop. Try stracing it and see what it's getting. Jeff - 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/
use of uninitialized pointer in jffs_create()
gcc kindly pointed me at jffs_create() with this warning :
fs/jffs/inode-v23.c:1279: warning: `inode' might be used uninitialized
in this function
And looking at the function :
static int
jffs_create(struct inode *dir, struct dentry *dentry, int mode,
struct nameidata *nd)
{
struct jffs_raw_inode raw_inode;
struct jffs_control *c;
struct jffs_node *node;
struct jffs_file *dir_f; /* JFFS representation of the directory. */
struct inode *inode;
int err;
truncate_inode_pages(&inode->i_data, 0);
...
I think it is correct. How on earth is that call to
truncate_inode_pages() going to avoid blowing up? inode has not yet
been initialized... Looks like a bug to me.
Unfortunately I don't know anything about this code, so I haven't
attempted to fix it.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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: RTL8139, the final patch ?
On Saturday 20 August 2005 21:53, you wrote: > I have a problem with it: > It's about patching, reverting, patching, reverting,... > I got lost. That's why I asked for a... "straighter" one :-) >> But I looked at what he said and found the real problem on my system (after >> all that): >> http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html > It's about a configuration option in the kernel? > The patch is about adding the option, if i'm right. No, what happened was on 2.6.2 all was well. When 2.6.3 came out I got these timeout errors on the NIC's - but using the 2.6.2 8139too.c file in 2.6.3 worked. Mr Hirofumi then took up the challenge and sent me patches. Slowly he resolved the issue, but the conclusion was it wasn't the code causing it. It was an option in my BIOS PCI level/edge settings as I posted. People on laptops get this error, like you, but there is no BIOS option as such... :-/ Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: sched_yield() makes OpenLDAP slow
Howard Chu writes:
> Nikita Danilov wrote:
> > That returns us to the core of the problem: sched_yield() is used to
> > implement a synchronization primitive and non-portable assumptions are
> > made about its behavior: SUS defines that after sched_yield() thread
> > ceases to run on the CPU "until it again becomes the head of its thread
> > list", and "thread list" discipline is only defined for real-time
> > scheduling policies. E.g.,
> >
> > int sched_yield(void)
> > {
> >return 0;
> > }
> >
> > and
> >
> > int sched_yield(void)
> > {
> >sleep(100);
> >return 0;
> > }
> >
> > are both valid sched_yield() implementation for non-rt (SCHED_OTHER)
> > threads.
> I think you're mistaken:
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0d4eaf3703131e86/da051ebe58976b00#da051ebe58976b00
>
> sched_yield() is required to be supported even if priority scheduling is
> not supported, and it is required to cause the calling thread (not
> process) to yield the processor.
Of course sched_yield() is required to be supported, the question is for
how long CPU is yielded. Here is the quote from the SUS (actually the
complete definition of sched_yield()):
The sched_yield() function shall force the running thread to
relinquish the processor until it again becomes the head of its
thread list.
As far as I can see, SUS doesn't specify how "thread list" is maintained
for non-RT scheduling policy, and implementation that immediately places
SCHED_OTHER thread that called sched_yield() back at the head of its
thread list is perfectly valid. Also valid is an implementation that
waits for 100 seconds and then places sched_yield() caller to the head
of the list, etc. Basically, while semantics of sched_yield() are well
defined for RT scheduling policy, for SCHED_OTHER policy standard leaves
it implementation defined.
>
> --
> -- Howard Chu
Nikita.
-
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: RTL8139, the final patch ?
On Sat, 2005-08-20 at 21:53 +0100, Nick Warne wrote: > Here is the 'final' post after Mr Hirofumi > found the cause of my issues: > http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1709.html I have a problem with it: It's about patching, reverting, patching, reverting,... I got lost. That's why I asked for a... "straighter" one :-) > But I looked at what he said and found the real problem on my system (after > all that): > http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html It's about a configuration option in the kernel? The patch is about adding the option, if i'm right. -- Administration & Formation à l'administration de serveurs dédiés: http://www.google.fr/search?q=aspo+infogerance+serveur - 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] Posix file attribute support on VFAT (take #2)
On Thu, Aug 18, 2005 at 07:52:23PM +0900, Hiroyuki Machida wrote: > Christoph Hellwig wrote: > >On Wed, Aug 17, 2005 at 04:07:03AM +0900, Machida, Hiroyuki wrote: > >>This is a take 2 of posix file attribute support on VFAT. > > > > > >Sorry, but this is far too scary. Please just use one of the sane > >filesystems linux supports. > > > > I would say that purpose of the feature is having ability to > build root fs for small embedded device, not support full posix > attributes top of VFAT. I think the situation is like uclinux, > which has no MMU support and many restriction, however it's still > very helpful for small embedded device. This doesn't seem so different from umsdos to me -- which was only removed from the kernel because it was unmaintained. It might have its place. However, I'd guess you'd need to demonstrate that someone is actually going to use and maintain this feature before it would be considered for inclusion in the kernel. -- Joseph Fannin [EMAIL PROTECTED] "Bull in pure form is rare; there is usually some contamination by data." -- William Graves Perry Jr. - 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: sched_yield() makes OpenLDAP slow
On Sat, 2005-08-20 at 11:38 -0700, Howard Chu wrote: > Nick Piggin wrote: > > Robert Hancock wrote: > > > I fail to see how sched_yield is going to be very helpful in this > > > situation. Since that call can sleep from a range of time ranging > > > from zero to a long time, it's going to give unpredictable results. > > > Well, not sleep technically, but yield the CPU for some undefined > > amount of time. > > Since the slapd server was not written to run in realtime, nor is it > commonly run on realtime operating systems, I don't believe predictable > timing here is a criteria we care about. One could say the same of > sigsuspend() by the way - it can pause a process for a range of time > ranging from zero to a long time. Should we tell application writers not > to use this function either, regardless of whether the developer thinks > they have a good reason to use it? Of course not. We should tell them that if they use sigsuspend() they cannot assume that the process will not wake up immediately. Lee - 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: [OT]Linus trademarks Linux?!!
On 8/20/05, Alejandro Bonilla Beeche <[EMAIL PROTECTED]> wrote: > On Fri, 2005-08-19 at 22:13 -0700, alan wrote: > > On Sat, 20 Aug 2005, Kernel Hacker wrote: > > > > > Friend, > > > What fact is behind this article > > > http://www.theinquirer.net/?article=25529. > > > > The article is also wrong. > > > > Try this one instead... > > > > http://os.newsforge.com/os/05/08/19/1842249.shtml?tid=2&tid=138 > > OK, now I would like to see a more official statement about this. Does > the linuxjournal.com pay $5000? > > If I ever do something commercial with linuxwireless.org, I will need to > pay $5000? > > Linus? > Linux being a registered trademark is old news. Linus clarified the whole "Linux is a registered trademark of Linus Torvalds" thing back in 2000 in a lengthy email to LKML. He explained both why Linux was registered as a trademark, why he has to enforce/police it to keep it, and what the groundrules regarding its use are (and don't worry, it's all quite sensible). You can find the email here : http://boudicca.tux.org/hypermail/linux-kernel/2000week04/0654.html -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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-git10 test report [x86_64](WITHOUT NVIDIA MODULE)
On Fri, Aug 19, 2005 at 09:22:09AM -0700, Peter Buckingham wrote: > >The machine is working quite a bit better with pci=noacpi in leu of > >disabling ACPI in the BIOS, but there are still those nasty errors in > >reference to the ACPI tables being broken: > >ACPI-0362: *** Error: Looking up [\_SB_.PCI0.LNK0] in namespace, > >AE_NOT_FOUND > >search_node 8101428572c0 start_node 8101428572c0 return_node > > > > since it doesn't look like you'll get a bios fix for this you may want > to look at building a custom dsdt. the kernel can load a custom dsdt > from an initrd/initramfs. have a look at the acpi site (acpi.sf.net?). > they talk about what's needed to do this. basically you can get your > dsdt from /proc/acpi/dsdt and disassemble it using the iasl tools, fix > it and then load it with an initrd. note that this is not really a > trivial task :-( Also, please file a bug report against the ACPI component at http://bugzilla.kernel.org . Ultimately the Linux ACPI component must deal with these sorts of errors, or convince the BIOS authors not to make them! -- Joseph Fannin [EMAIL PROTECTED] "That's all I have to say about that." -- Forrest Gump. - 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: sched_yield() makes OpenLDAP slow
Lee Revell wrote: On Sat, 2005-08-20 at 11:38 -0700, Howard Chu wrote: > But I also found that I needed to add a new yield(), to work around > yet another unexpected issue on this system - we have a number of > threads waiting on a condition variable, and the thread holding the > mutex signals the var, unlocks the mutex, and then immediately > relocks it. The expectation here is that upon unlocking the mutex, > the calling thread would block while some waiting thread (that just > got signaled) would get to run. In fact what happened is that the > calling thread unlocked and relocked the mutex without allowing any > of the waiting threads to run. In this case the only solution was > to insert a yield() after the mutex_unlock(). That's exactly the behavior I would expect. Why would you expect unlocking a mutex to cause a reschedule, if the calling thread still has timeslice left? That's beside the point. Folks are making an assertion that sched_yield() is meaningless; this example demonstrates that there are cases where sched_yield() is essential. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ - 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] Permissions don't stick on ConfigFS attributes (revised)
On Saturday 20 August 2005 13:01, Greg KH wrote:
> On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
> > Permissions set on ConfigFS attributes (aka files) do not stick.
>
> The recent changes to sysfs should be ported to configfs to do this.
No, it should go the other way, my fix is better. It would not require sysfs
to have its own version of setattr. What I do like about Maneesh's fix is the
handling of other inode attributes besides mode flags, however that is a
detail, let's get the structural elements right first.
The revised patch fixes the vanishing permissions bug and kills the configfs
bogon that made my first attempt subtly wrong (changed permissions for all
attribute files instead of just the chmoded one).
diff -up --recursive 2.6.12-mm2.clean/fs/configfs/dir.c
2.6.12-mm2/fs/configfs/dir.c
--- 2.6.12-mm2.clean/fs/configfs/dir.c 2005-08-12 00:53:06.0 -0400
+++ 2.6.12-mm2/fs/configfs/dir.c2005-08-20 16:16:34.0 -0400
@@ -64,6 +64,17 @@ static struct dentry_operations configfs
.d_delete = configfs_d_delete,
};
+static int configfs_d_delete_attr(struct dentry *dentry)
+{
+ ((struct configfs_dirent *)dentry->d_fsdata)->s_mode =
dentry->d_inode->i_mode;
+ return 1;
+}
+
+static struct dentry_operations configfs_attr_dentry_ops = {
+ .d_delete = configfs_d_delete_attr,
+ .d_iput = configfs_d_iput,
+};
+
/*
* Allocates a new configfs_dirent and links it to the parent configfs_dirent
*/
@@ -238,14 +249,11 @@ static void configfs_remove_dir(struct c
*/
static int configfs_attach_attr(struct configfs_dirent * sd, struct dentry *
dentry)
{
- struct configfs_attribute * attr = sd->s_element;
- int error;
-
- error = configfs_create(dentry, (attr->ca_mode & S_IALLUGO) | S_IFREG,
init_file);
+ int error = configfs_create(dentry, sd->s_mode, init_file);
if (error)
return error;
- dentry->d_op = &configfs_dentry_ops;
+ dentry->d_op = &configfs_attr_dentry_ops;
dentry->d_fsdata = configfs_get(sd);
sd->s_dentry = dentry;
d_rehash(dentry);
-
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: sched_yield() makes OpenLDAP slow
On Sat, 2005-08-20 at 11:38 -0700, Howard Chu wrote: > But I also found that I needed to add a new > yield(), to work around yet another unexpected issue on this system - > we have a number of threads waiting on a condition variable, and the > thread holding the mutex signals the var, unlocks the mutex, and then > immediately relocks it. The expectation here is that upon unlocking > the mutex, the calling thread would block while some waiting thread > (that just got signaled) would get to run. In fact what happened is > that the calling thread unlocked and relocked the mutex without > allowing any of the waiting threads to run. In this case the only > solution was to insert a yield() after the mutex_unlock(). That's exactly the behavior I would expect. Why would you expect unlocking a mutex to cause a reschedule, if the calling thread still has timeslice left? Lee - 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: RTL8139, the final patch ?
Rakotomandimby Mihamina wrote: > Hi, > > I now use a notebook that uses RTL8139, and I encounter exactly the same > problems as this: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1289.html > > I know use Fedora Core 4 on this box. > With a Linux FC4 kernel (not customized yet). > > As well as I still encounter the problem, I guess the solution has not > been found. Hi, this was my original post. I did indeed get a solution - and occasionally I see people still have this issue and some of them mail me, so I have a prepared mail :-) Here is the 'final' post after Mr Hirofumi found the cause of my issues: http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1709.html But I looked at what he said and found the real problem on my system (after all that): http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: Fix up befs compile.
On Sat, Aug 20, 2005 at 08:58:07PM +0100, Al Viro wrote:
> On Sat, Aug 20, 2005 at 03:48:40PM -0400, Dave Jones wrote:
> > fs/befs/linuxvfs.c:466: error: conflicting types for 'befs_follow_link'
> > fs/befs/linuxvfs.c:44: error: previous declaration of 'befs_follow_link'
> > was here
> > fs/befs/linuxvfs.c: In function 'befs_follow_link':
> > fs/befs/linuxvfs.c:490: warning: return makes integer from pointer without
> > a cast
>
> It should be void *, not void.
Duh. Yes. of course.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.12/fs/befs/linuxvfs.c~2005-08-20 15:46:30.0 -0400
+++ linux-2.6.12/fs/befs/linuxvfs.c 2005-08-20 15:47:25.0 -0400
@@ -461,7 +461,7 @@ befs_destroy_inodecache(void)
* The data stream become link name. Unless the LONG_SYMLINK
* flag is set.
*/
-static int
+static void *
befs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
befs_inode_info *befs_ino = BEFS_I(dentry->d_inode);
Dave
-
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: [RFC][PATCH] Rename PageChecked as PageMiscFS
On Saturday 20 August 2005 20:45, David Howells wrote: > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > Biased. Fs is a mixed case acronym, nuff said. > > But I'm still right:-) Of course you are! We're only impugning your taste, not your logic ;-) OK, the questions re your global consistency model are a bazillion times more significant. I have not forgotten about that, please stay tuned. Regards, Daniel - 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: Fix up befs compile.
On Sat, Aug 20, 2005 at 03:48:40PM -0400, Dave Jones wrote: > fs/befs/linuxvfs.c:466: error: conflicting types for 'befs_follow_link' > fs/befs/linuxvfs.c:44: error: previous declaration of 'befs_follow_link' was > here > fs/befs/linuxvfs.c: In function 'befs_follow_link': > fs/befs/linuxvfs.c:490: warning: return makes integer from pointer without a > cast > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > It should be void *, not void. - 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: sched_yield() makes OpenLDAP slow
Nikita Danilov wrote:
That returns us to the core of the problem: sched_yield() is used to
implement a synchronization primitive and non-portable assumptions are
made about its behavior: SUS defines that after sched_yield() thread
ceases to run on the CPU "until it again becomes the head of its thread
list", and "thread list" discipline is only defined for real-time
scheduling policies. E.g.,
int sched_yield(void)
{
return 0;
}
and
int sched_yield(void)
{
sleep(100);
return 0;
}
are both valid sched_yield() implementation for non-rt (SCHED_OTHER)
threads.
I think you're mistaken:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0d4eaf3703131e86/da051ebe58976b00#da051ebe58976b00
sched_yield() is required to be supported even if priority scheduling is
not supported, and it is required to cause the calling thread (not
process) to yield the processor.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
-
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/
Fix up befs compile.
fs/befs/linuxvfs.c:466: error: conflicting types for 'befs_follow_link'
fs/befs/linuxvfs.c:44: error: previous declaration of 'befs_follow_link' was
here
fs/befs/linuxvfs.c: In function 'befs_follow_link':
fs/befs/linuxvfs.c:490: warning: return makes integer from pointer without a
cast
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.12/fs/befs/linuxvfs.c~2005-08-20 15:46:30.0 -0400
+++ linux-2.6.12/fs/befs/linuxvfs.c 2005-08-20 15:47:25.0 -0400
@@ -461,7 +461,7 @@ befs_destroy_inodecache(void)
* The data stream become link name. Unless the LONG_SYMLINK
* flag is set.
*/
-static int
+static void
befs_follow_link(struct dentry *dentry, struct nameidata *nd)
{
befs_inode_info *befs_ino = BEFS_I(dentry->d_inode);
@@ -487,7 +487,6 @@ befs_follow_link(struct dentry *dentry,
}
nd_set_link(nd, link);
- return NULL;
}
static void befs_put_link(struct dentry *dentry, struct nameidata *nd, void *p)
-
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 patch] mm/filemap.c: make two functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6-mm1/mm/filemap.c.old 2005-08-20 14:37:27.0
+0200
+++ linux-2.6.13-rc6-mm1/mm/filemap.c 2005-08-20 14:46:24.0 +0200
@@ -2034,7 +2034,7 @@
}
EXPORT_SYMBOL(generic_file_buffered_write);
-ssize_t
+static ssize_t
__generic_file_aio_write_nolock(struct kiocb *iocb, const struct iovec *iov,
unsigned long nr_segs, loff_t *ppos)
{
@@ -2134,7 +2134,7 @@
return ret;
}
-ssize_t
+static ssize_t
__generic_file_write_nolock(struct file *file, const struct iovec *iov,
unsigned long nr_segs, loff_t *ppos)
{
-
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/
[RFC: -mm patch] kcalloc(): INT_MAX -> ULONG_MAX
This change could (at least in theory) allow a compiler better
optimization (especially in the n=1 case).
The practical effect seems to be nearly zero:
text data bss dechex filename
256172075850138 1827016 332943611fc0819 vmlinux-old
256171915850138 1827016 332943451fc0809 vmlinux-patched
Is there any reason against this patch?
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6-mm1-full/include/linux/slab.h.old 2005-08-20
04:10:09.0 +0200
+++ linux-2.6.13-rc6-mm1-full/include/linux/slab.h 2005-08-20
04:11:04.0 +0200
@@ -113,7 +113,7 @@
*/
static inline void *kcalloc(size_t n, size_t size, unsigned int __nocast flags)
{
- if (n != 0 && size > INT_MAX / n)
+ if (n != 0 && size > ULONG_MAX / n)
return NULL;
return kzalloc(n * size, flags);
}
-
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-rt9
On Fri, 2005-08-19 at 11:43 -0700, Paul E. McKenney wrote: > On Fri, Aug 19, 2005 at 08:30:05PM +0200, Peter Zijlstra wrote: > > On Fri, 2005-08-19 at 18:56 +0200, Peter Zijlstra wrote: > > > Hi Ingo, Paul, others, > > > > > > I'm trying to run a user-mode-linux guest under the RT kernel however > > > the uml process never gets out of the calibrate delay loop. It seems as > > > if the signal never gets through. > > > > > one clarification: the guest kernel is a non -rt kernel, a modified > > 2.6.13-rc6 in my case. > > > > > A non -rt host kernel does work (with a similar .config). > > > > > > Could this be related to pauls task list changes? > > Possibly. What signal? This is a signal to a single process, right? > Jeff, could you help us out here? What exactly does uml need to get out of the calibrate delay loop? Kind regards, Peter Zijlstra - 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 patch] drivers/scsi/constants.c should include scsi_dbg.h
C files should include the files with the prototypes for their global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc6-mm1/drivers/scsi/constants.c.old 2005-08-20 14:42:12.0 +0200 +++ linux-2.6.13-rc6-mm1/drivers/scsi/constants.c 2005-08-20 14:43:03.0 +0200 @@ -17,6 +17,7 @@ #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/
[2.6 patch] include/linux/quotaops.h: "extern inline" doesn't make sense
"extern inline" doesn't make sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/quotaops.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.13-rc6-mm1/include/linux/quotaops.h.old 2005-08-20
14:40:53.0 +0200
+++ linux-2.6.13-rc6-mm1/include/linux/quotaops.h 2005-08-20
14:41:30.0 +0200
@@ -198,38 +198,38 @@
#define DQUOT_SYNC(sb) do { } while(0)
#define DQUOT_OFF(sb) do { } while(0)
#define DQUOT_TRANSFER(inode, iattr) (0)
-extern __inline__ int DQUOT_PREALLOC_SPACE_NODIRTY(struct inode *inode,
qsize_t nr)
+static inline int DQUOT_PREALLOC_SPACE_NODIRTY(struct inode *inode, qsize_t nr)
{
inode_add_bytes(inode, nr);
return 0;
}
-extern __inline__ int DQUOT_PREALLOC_SPACE(struct inode *inode, qsize_t nr)
+static inline int DQUOT_PREALLOC_SPACE(struct inode *inode, qsize_t nr)
{
DQUOT_PREALLOC_SPACE_NODIRTY(inode, nr);
mark_inode_dirty(inode);
return 0;
}
-extern __inline__ int DQUOT_ALLOC_SPACE_NODIRTY(struct inode *inode, qsize_t
nr)
+static inline int DQUOT_ALLOC_SPACE_NODIRTY(struct inode *inode, qsize_t nr)
{
inode_add_bytes(inode, nr);
return 0;
}
-extern __inline__ int DQUOT_ALLOC_SPACE(struct inode *inode, qsize_t nr)
+static inline int DQUOT_ALLOC_SPACE(struct inode *inode, qsize_t nr)
{
DQUOT_ALLOC_SPACE_NODIRTY(inode, nr);
mark_inode_dirty(inode);
return 0;
}
-extern __inline__ void DQUOT_FREE_SPACE_NODIRTY(struct inode *inode, qsize_t
nr)
+static inline void DQUOT_FREE_SPACE_NODIRTY(struct inode *inode, qsize_t nr)
{
inode_sub_bytes(inode, nr);
}
-extern __inline__ void DQUOT_FREE_SPACE(struct inode *inode, qsize_t nr)
+static inline void DQUOT_FREE_SPACE(struct inode *inode, qsize_t nr)
{
DQUOT_FREE_SPACE_NODIRTY(inode, nr);
mark_inode_dirty(inode);
-
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/
[-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote: >... > Changes since 2.6.13-rc5-mm1: >... > git-net.patch >... > Subsystem trees >... This breaks the compilation with CONFIG_PROC_FS=n: <-- snip --> ... CC net/core/sysctl_net_core.o net/core/sysctl_net_core.c:50: error: 'sysctl_wmem_default' undeclared here (not in a function) net/core/sysctl_net_core.c:58: error: 'sysctl_rmem_default' undeclared here (not in a function) make[2]: *** [net/core/sysctl_net_core.o] Error 1 <-- snip --> The fix is simple. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc6-mm1-full/include/net/sock.h.old2005-08-20 15:39:23.0 +0200 +++ linux-2.6.13-rc6-mm1-full/include/net/sock.h2005-08-20 15:39:39.0 +0200 @@ -1372,9 +1372,7 @@ extern int sysctl_optmem_max; #endif -#ifdef CONFIG_PROC_FS extern __u32 sysctl_wmem_default; extern __u32 sysctl_rmem_default; -#endif #endif /* _SOCK_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/
SCSI- unexpected disconnect with kernel-2.6.13-r6
I am using a LSIU160/Symbios 53c1010 Ultra3 scsi adapter and it works at full speed (75 MB/sec) with kernel-2.6.12. And dmesg shows: kernel: target0:0:0: Beginning Domain Validation kernel: target0:0:0: asynchronous. kernel: WIDTH IS 1 kernel: target0:0:0: wide asynchronous. kernel: target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62) kernel: target0:0:0: Ending Domain Validation kernel: sym1: <1010-33> rev 0x1 at pci :01:07.1 irq 11 kernel: sym1: Symbios NVRAM, ID 7, Fast-80, SE, parity checking kernel: sym1: open drain IRQ line driver kernel: sym1: using LOAD/STORE-based firmware. kernel: sym1: handling phase mismatch from SCRIPTS. kernel: sym1: SCSI BUS has been reset. kernel: scsi1 : sym-2.2.0 kernel: libata version 1.11 loaded. With kernel-2.6.13-r6 the speed drops back to 2.70 MB/sec because of validation failure and dmesg shows: kernel: target0:0:0: Beginning Domain Validation kernel: target0:0:0: asynchronous. kernel: target0:0:0: wide asynchronous. kernel: target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS ( kernel: sym0: unexpected disconnect kernel: target0:0:0: Write Buffer failure 700ff kernel: target0:0:0: Domain Validation Disabing Information units kernel: 0:0:0:0: phase change 6-7 [EMAIL PROTECTED] resid=10. kernel: target0:0:0: asynchronous. kernel: sym0: unexpected disconnect target0:0:0: Write Buffer failure 700ff target0:0:0: Domain Validation detected failure, dropping back kernel: target0:0:0: asynchronous. target0:0:0: Ending Domain Validation kernel: sym1: <1010-33> rev 0x1 at pci :01:07.1 irq 11 kernel: sym1: Symbios NVRAM, ID 7, Fast-80, SE, parity checkingkernel: sym1: open drain IRQ line driver, using on-chip SRAM kernel: sym1: using LOAD/STORE-based firmware. kernel: sym1: handling phase mismatch from SCRIPTS. kernel: sym1: SCSI BUS has been reset. kernel: scsi1 : sym-2.2.1 kernel: libata version 1.11 loaded. The kernel config has: CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set - 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 patch] drivers/ide/: possible cleanups
This patch contains the following possible cleanups:
- pci/cy82c693.c: make a needlessly global function static
- remove the following unneeded EXPORT_SYMBOL's:
- ide-taskfile.c: do_rw_taskfile
- ide-iops.c: default_hwif_iops
- ide-iops.c: default_hwif_transport
- ide-iops.c: wait_for_ready
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ide/ide-iops.c |6 --
drivers/ide/ide-taskfile.c |2 --
drivers/ide/pci/cy82c693.c |2 +-
3 files changed, 1 insertion(+), 9 deletions(-)
--- linux-2.6.11-rc3-mm1-full/drivers/ide/ide-taskfile.c.old2005-02-05
02:57:03.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/ide/ide-taskfile.c2005-02-05
02:57:12.0 +0100
@@ -161,8 +161,6 @@
return ide_stopped;
}
-EXPORT_SYMBOL(do_rw_taskfile);
-
/*
* set_multmode_intr() is invoked on completion of a WIN_SETMULT cmd.
*/
--- linux-2.6.12-rc2-mm3-full/drivers/ide/pci/cy82c693.c.old2005-04-17
21:11:22.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ide/pci/cy82c693.c2005-04-17
21:11:30.0 +0200
@@ -469,7 +469,7 @@
static __initdata ide_hwif_t *primary;
-void __devinit init_iops_cy82c693(ide_hwif_t *hwif)
+static void __devinit init_iops_cy82c693(ide_hwif_t *hwif)
{
if (PCI_FUNC(hwif->pci_dev->devfn) == 1)
primary = hwif;
--- linux-2.6.12-rc2-mm3-full/drivers/ide/ide-iops.c.old2005-04-17
21:12:44.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ide/ide-iops.c2005-04-17
21:12:54.0 +0200
@@ -104,8 +104,6 @@
hwif->INSL = ide_insl;
}
-EXPORT_SYMBOL(default_hwif_iops);
-
/*
* MMIO operations, typically used for SATA controllers
*/
@@ -329,8 +327,6 @@
hwif->atapi_output_bytes= atapi_output_bytes;
}
-EXPORT_SYMBOL(default_hwif_transport);
-
/*
* Beginning of Taskfile OPCODE Library and feature sets.
*/
@@ -525,8 +525,6 @@
return 0;
}
-EXPORT_SYMBOL(wait_for_ready);
-
/*
* This routine busy-waits for the drive status to be not "busy".
* It then checks the status for all of the "good" bits and none
-
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 patch] sound/core/memalloc.c: fix PROC_FS=n compilation
This patch fixes the following compile error with CONFIG_PROC_FS=n: <-- snip --> ... CC sound/core/memalloc.o sound/core/memalloc.c: In function 'snd_mem_exit': sound/core/memalloc.c:658: error: 'snd_mem_proc' undeclared (first use in this function) sound/core/memalloc.c:658: error: (Each undeclared identifier is reported only once sound/core/memalloc.c:658: error: for each function it appears in.) make[2]: *** [sound/core/memalloc.o] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc6-mm1-full/sound/core/memalloc.c.old 2005-08-20 15:12:55.0 +0200 +++ linux-2.6.13-rc6-mm1-full/sound/core/memalloc.c 2005-08-20 15:16:55.0 +0200 @@ -506,13 +506,13 @@ up(&list_mutex); } +static struct proc_dir_entry *snd_mem_proc; #ifdef CONFIG_PROC_FS /* * proc file interface */ #define SND_MEM_PROC_FILE "driver/snd-page-alloc" -static struct proc_dir_entry *snd_mem_proc; static int snd_mem_proc_read(char *page, char **start, off_t off, int count, int *eof, void *data) - 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] adapt scripts/ver_linux to new util-linux version strings
On Sat, Aug 20, 2005 at 09:55:32AM +0400, Alexey Dobriyan wrote:
> On Sat, Aug 20, 2005 at 05:58:53AM +0200, Adrian Bunk wrote:
> > --- linux-2.6.13-rc6-mm1-full/scripts/ver_linux.old
> > +++ linux-2.6.13-rc6-mm1-full/scripts/ver_linux
>
> > -fdformat --version | awk -F\- '{print "util-linux", $NF}'
> > +fdformat --version | awk '{print "util-linux", $NF}' \
> > +| awk -F\) '{print $1}'
> >
> > -mount --version | awk -F\- '{print "mount ", $NF}'
> > +mount --version | awk '{print "mount ", $NF}' | \
> > +awk -F\) '{print $1}'
>
> -util-linux 2.12i
> -mount 2.12i
> +util-linux util-linux-2.12i
> +mount mount-2.12i
> ^^
>
> Is this intentional?
After this patch, the new format is parsed correctly instead of
completely wrong.
You've found the small regression parsing the old format.
IMHO this is not a problem. If you disagree, feel free to send a better
patch.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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 2.6.13-rc6] i386: semaphore ownership tracking
On Sat, 2005-08-20 at 03:07 -0400, Chuck Ebbert wrote: > On Fri, 19 Aug 2005 at 20:02:27 -0700, Andrew Morton wrote: > > > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > > > > This patch enables tracking semaphore ownership. > > > > Why? I can't think of any bug in recent years which needed this.. > > It might be useful in new driver development. OTOH it is really ugly > even if it's a small patch. How is it different from the ownership tracking used for PI in the -rt kernel? Lee - 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: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
On Sat, 2005-08-20 at 10:31 +1000, Con Kolivas wrote: > It's an X problem and it's being fixed. Get over it, we're not tuning > the scheduler for a broken app. > You're right, this problem seems much, much better in Xorg 6.8.2. I think the Damage extension might be responsible. There's definitely something different happening because when I switch windows quickly, instead of a grey box that gets slowly re-packed with widgets, I see a black box that packs very fast, and seems to be filled in large rectangular chunks rather than one widget at a time. X is also using a lot less CPU. Very nice work... Lee - 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.13-rc6: halt instead of reboot
I'm currently running 2.6.13-rc6+git as of today and whan I tell my computer to reboot, it starts a reboot as sual and when it reached kernel telling "Rebooting" the computer halts instead. I noticed it just with an earlier post-rc6 snapshot and it's still there with current git. PC, Duron 1.3 GHz CPU, VIA 686A chipset mainboard. Reboot has worked normally before. config: CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_EXPERIMENTAL=y CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_X86_PC=y CONFIG_MK7=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_REBOOTFIXUPS=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m CONFIG_NOHIGHMEM=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_PHYSICAL_START=0x10 CONFIG_PM=y CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_APM=m CONFIG_APM_IGNORE_USER_SUSPEND=y CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_DISPLAY_BLANK=y CONFIG_APM_REAL_MODE_POWER_OFF=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_MULTIPATH_CACHED=y CONFIG_IP_ROUTE_MULTIPATH_RR=m CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m CONFIG_IP_ROUTE_MULTIPATH_DRR=m CONFIG_IP_ROUTE_VERBOSE=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m CONFIG_IPV6_TUNNEL=m CONFIG_NETFILTER=y CONFIG_BRIDGE_NETFILTER=y CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_REALM=m CONFIG_IP_NF_MATCH_SCTP=m CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQ
Re: sched_yield() makes OpenLDAP slow
Nick Piggin wrote: Robert Hancock wrote: > I fail to see how sched_yield is going to be very helpful in this > situation. Since that call can sleep from a range of time ranging > from zero to a long time, it's going to give unpredictable results. Well, not sleep technically, but yield the CPU for some undefined amount of time. Since the slapd server was not written to run in realtime, nor is it commonly run on realtime operating systems, I don't believe predictable timing here is a criteria we care about. One could say the same of sigsuspend() by the way - it can pause a process for a range of time ranging from zero to a long time. Should we tell application writers not to use this function either, regardless of whether the developer thinks they have a good reason to use it? > It seems to me that this sort of thing is why we have POSIX pthread > synchronization primitives.. sched_yield is basically there for a > process to indicate that "what I'm doing doesn't matter much, let > other stuff run". Any other use of it generally constitutes some > kind of hack. In terms of transaction recovery, we do an exponential backoff on the retries, because our benchmarks showed that under heavy lock contention, immediate retries only made things worse. In fact, having arbitrarily long backoff delays here was shown to improve transaction throughput. (We use select() with an increasing timeval in combination with the yield() call. One way or another we get a longer delay as desired.) sched_yield is there for a *thread* to indicate "what I'm doing doesn't matter much, let other stuff run." I suppose it may be a hack. But then so is TCP congestion control. In both cases, empirical evidence indicates the hack is worthwhile. If you haven't done the analysis then you're in no position to deny the value of the approach. In SCHED_OTHER mode, you're right, sched_yield is basically meaningless. In a realtime system, there is a very well defined and probably useful behaviour. Eg. If 2 SCHED_FIFO processes are running at the same priority, One can call sched_yield to deterministically give the CPU to the other guy. Well yes, the point of a realtime system is to provide deterministic response times to unpredictable input. I'll note that we removed a number of the yield calls (that were in OpenLDAP 2.2) for the 2.3 release, because I found that they were redundant and causing unnecessary delays. My own test system is running on a Linux 2.6.12.3 kernel (installed over a SuSE 9.2 x86_64 distro), and OpenLDAP 2.3 runs perfectly well here, now that those redundant calls have been removed. But I also found that I needed to add a new yield(), to work around yet another unexpected issue on this system - we have a number of threads waiting on a condition variable, and the thread holding the mutex signals the var, unlocks the mutex, and then immediately relocks it. The expectation here is that upon unlocking the mutex, the calling thread would block while some waiting thread (that just got signaled) would get to run. In fact what happened is that the calling thread unlocked and relocked the mutex without allowing any of the waiting threads to run. In this case the only solution was to insert a yield() after the mutex_unlock(). So again, for those of you claiming "oh, all you need to do is use a condition variable or any of the other POSIX synchronization primitives" - yes, that's a nice theory, but reality says otherwise. To say that sched_yield is basically meaningless is far overstating your point. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ - 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/
RTL8139, the final patch ?
Hi, I now use a notebook that uses RTL8139, and I encounter exactly the same problems as this: http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1289.html I know use Fedora Core 4 on this box. With a Linux FC4 kernel (not customized yet). As well as I still encounter the problem, I guess the solution has not been found. Is there a summary of what should be done to resolv it? I would like to apply the needed patches. The only problem is I am not a very very good C coder so that I could do it the wrong way. Thank you :-) -- Administration & Formation à l'administration de serveurs dédiés: http://www.google.fr/search?q=aspo+infogerance+serveur - 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: open("foo", 3)
On Sat, 2005-08-20 at 10:30 -0700, Linus Torvalds wrote:
>
> On Sat, 20 Aug 2005, Miklos Szeredi wrote:
> >
> > My question is: is this deliberate or accidental? Wouldn't it be more
> > logical to not require any permission to open such file? Or is there
> > some security concern with that?
>
> It's deliberate but historical. It's been a long time since I worked on
> it, but it was meant for "special opens".
>
> I _think_ it was used for things like "open block device without media
> check" etc (we use O_NONBLOCK for that now), and it was used for directory
> opens before we had O_DIRECTORY. (It's literally been years, so my
> recollection may be bogus).
>
> I don't think anything uses it any more, and it should probably be
> deprecated rather than extended upon.
It may also be dangerous, since I see several drivers using
if ((filp->f_flags & O_ACCMODE) != RD_ONLY) {
/* do something assuming we have write access */
...
}
Perhaps that access mode may not allow for getting to code like this,
but, since it's so old, you may have those that forget about the 3 mode,
and we lose the protection somewhere along the line.
It probably be better to not allow for it. Or maybe an audit of such
code needs to be replaced with:
if (filp->f_mode & FMODE_WRITE) {
...
}
Just my $0.02
-- Steve
-
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 0/5] improve i2c probing
Hmm, some of this resembles my prototype from last month: http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013012.html Both ended up with new driver probe() methods attaching to *devices* not to busses, and used the probe signature the i2c core already handles. That helps eliminate one of the surprises hitting anyone starting to use the I2C driver stack. But not the more fundamental one... What would you think about actually making I2C probing work more like standard driver model probing, instead? That is, have the probe method signature look like this: int probe(struct i2c_client *dev, void *driver_data) In normal driver model usage, infrastructure creates the devices, and the device drivers just bind to them. But I2C doesn't support that even for the submodel where it's very appropriate: devices that have been probed, or which (as with platform_bus) were explicitly declared to exist. I2C drivers would either continue the old school way ... or could start acting more like they do in other mainstream Linux driver frameworks. - Dave - 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 2.6.13-rc6-rt9] PI aware dynamic priority adjustment
Thomas Gleixner wrote:
>
> On Sat, 2005-08-20 at 18:10 +0400, Oleg Nesterov wrote:
>
> > posix_timer_event() first checks that the thread (SIGEV_THREAD_ID
> > case) does not have PF_EXITING flag, then it calls send_sigqueue()
> > which locks task list. But if the thread exits in between the kernel
> > will oops.
>
> > posix_timer_event() runs under k_itimer.it_lock, but this does not
> > help if that thread was not the only one in thread group, in this
> > case we don't call exit_itimers().
>
> I added exit_notify_itimers() for that case. It is synchronized vs.
> posix_timer_event() via the timer lock and therefor protects against the
> race described above.
>
> It solves the problem for the only user of send_sigqueue for now, but I
> think we should have a more general interface to such functionality to
> allow simple usage.
>
> tglx
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
> diff -uprN --exclude-from=/usr/local/bin/diffit.exclude
> linux-2.6.13-rc6/include/linux/sched.h
> linux-2.6.13-rc6.work/include/linux/sched.h
> --- linux-2.6.13-rc6/include/linux/sched.h 2005-08-13 12:25:56.0
> +0200
> +++ linux-2.6.13-rc6.work/include/linux/sched.h 2005-08-20 17:43:36.0
> +0200
> @@ -1051,6 +1051,7 @@ extern void __exit_signal(struct task_st
> extern void exit_sighand(struct task_struct *);
> extern void __exit_sighand(struct task_struct *);
> extern void exit_itimers(struct signal_struct *);
> +extern void exit_notify_itimers(struct signal_struct *);
>
> extern NORET_TYPE void do_group_exit(int);
>
> diff -uprN --exclude-from=/usr/local/bin/diffit.exclude
> linux-2.6.13-rc6/kernel/posix-timers.c
> linux-2.6.13-rc6.work/kernel/posix-timers.c
> --- linux-2.6.13-rc6/kernel/posix-timers.c 2005-08-13 12:25:58.0
> +0200
> +++ linux-2.6.13-rc6.work/kernel/posix-timers.c 2005-08-20 17:43:36.0
> +0200
> @@ -1169,6 +1169,33 @@ void exit_itimers(struct signal_struct *
> }
>
> /*
> + * This is called by __exit_signal, when there are still references to
> + * the shared signal_struct
> + */
> +void exit_notify_itimers(struct signal_struct *sig)
> +{
> + struct k_itimer *timer;
> + struct list_head *tmp;
> + unsigned long flags;
> +
> + list_for_each(tmp, &sig->posix_timers) {
> +
> + timer = list_entry(tmp, struct k_itimer, list);
> +
> + /* Protect against posix_timer_fn */
> + spin_lock_irqsave(&timer->it_lock, flags);
I think this is deadlockable. We already (release_task) hold
tasklist_lock here. What if this timer has no SIGEV_THREAD_ID ?
posix_timer_fn locks timer->it_lock first, then locks tasklist_lock
in send_group_sigqueue().
Also, sys_timer_delete() locks ->it_lock, then ->sighand.lock.
I think the better fix would be re-check ->sighand in send_sigqueue,
like Paul's patches do.
Oleg.
-
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: [Documentation] Use doxygen or another tool to generate a documentation ?
On Sat, Aug 20, 2005 at 11:19:41AM +0200, Stephane Wirtel wrote: > Le Saturday 20 August 2005 a 09:08, Sam Ravnborg ecrivait: > > > > > > Ok, with scripts/kernel-doc, I can produce some html files containing > > > the functions' documentation. > > > > > > make pdfdocs or others targets don't work :| > > > > You probarly need some additional packages. > > But it's not easy to help you with no log of what happened. > Yes, sorry, > > Kernel : 2.6.12 from the git repository of Linus. > > In make_docs.log.tar.bz2, you can find log files from make htmldocs, > make psdocs and make pdfdocs. >From your log-files I could not see what went wrong. It seems to be error in the generated files. Maybe Martin can help - Martin? Sam - 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.13-rc6-mm1: git-ocfs2.patch breaks jffs
On Fri, Aug 19, 2005 at 04:33:31AM -0700, Andrew Morton wrote: >... > Changes since 2.6.13-rc5-mm1: >... > git-ocfs2.patch >... > Subsystem trees >... gcc correctly tells that at least a part of this patch incorrect (not that gcc says "is used", not "might be used"): <-- snip --> ... CC fs/jffs/inode-v23.o fs/jffs/inode-v23.c: In function 'jffs_create': fs/jffs/inode-v23.c:1282: warning: 'inode' is used uninitialized in this function ... <-- snip --> Looking at the code, it's trivial to verify that gcc is right. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: open("foo", 3)
On Sat, 20 Aug 2005, Miklos Szeredi wrote: > > My question is: is this deliberate or accidental? Wouldn't it be more > logical to not require any permission to open such file? Or is there > some security concern with that? It's deliberate but historical. It's been a long time since I worked on it, but it was meant for "special opens". I _think_ it was used for things like "open block device without media check" etc (we use O_NONBLOCK for that now), and it was used for directory opens before we had O_DIRECTORY. (It's literally been years, so my recollection may be bogus). I don't think anything uses it any more, and it should probably be deprecated rather than extended upon. Linus - 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 send_sigqueue() vs thread exit race
[PATCH] fix send_sigqueue() vs thread exit race
posix_timer_event() first checks that the thread (SIGEV_THREAD_ID
case) does not have PF_EXITING flag, then it calls send_sigqueue()
which locks task list. But if the thread exits in between the kernel
will oops (->sighand == NULL after __exit_sighand).
This patch moves the PF_EXITING check into the send_sigqueue(), it
must be done atomically under tasklist_lock. When send_sigqueue()
detects exiting thread it returns -1. In that case posix_timer_event
will send the signal to thread group.
Also, this patch fixes task_struct use-after-free in posix_timer_event.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 2.6.13-rc6/kernel/signal.c~ 2005-08-18 23:10:28.0 +0400
+++ 2.6.13-rc6/kernel/signal.c 2005-08-20 23:05:21.0 +0400
@@ -1366,16 +1366,16 @@ send_sigqueue(int sig, struct sigqueue *
unsigned long flags;
int ret = 0;
- /*
-* We need the tasklist lock even for the specific
-* thread case (when we don't need to follow the group
-* lists) in order to avoid races with "p->sighand"
-* going away or changing from under us.
-*/
BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
- read_lock(&tasklist_lock);
+ read_lock(&tasklist_lock);
+
+ if (unlikely(p->flags & PF_EXITING)) {
+ ret = -1;
+ goto out_err;
+ }
+
spin_lock_irqsave(&p->sighand->siglock, flags);
-
+
if (unlikely(!list_empty(&q->list))) {
/*
* If an SI_TIMER entry is already queue just increment
@@ -1385,7 +1385,7 @@ send_sigqueue(int sig, struct sigqueue *
BUG();
q->info.si_overrun++;
goto out;
- }
+ }
/* Short-circuit ignored signals. */
if (sig_ignored(p, sig)) {
ret = 1;
@@ -1400,8 +1400,10 @@ send_sigqueue(int sig, struct sigqueue *
out:
spin_unlock_irqrestore(&p->sighand->siglock, flags);
+out_err:
read_unlock(&tasklist_lock);
- return(ret);
+
+ return ret;
}
int
--- 2.6.13-rc6/kernel/posix-timers.c~ 2005-08-18 21:37:08.0 +0400
+++ 2.6.13-rc6/kernel/posix-timers.c2005-08-20 23:21:23.0 +0400
@@ -427,21 +427,23 @@ int posix_timer_event(struct k_itimer *t
timr->sigq->info.si_code = SI_TIMER;
timr->sigq->info.si_tid = timr->it_id;
timr->sigq->info.si_value = timr->it_sigev_value;
+
if (timr->it_sigev_notify & SIGEV_THREAD_ID) {
- if (unlikely(timr->it_process->flags & PF_EXITING)) {
- timr->it_sigev_notify = SIGEV_SIGNAL;
- put_task_struct(timr->it_process);
- timr->it_process = timr->it_process->group_leader;
- goto group;
- }
- return send_sigqueue(timr->it_sigev_signo, timr->sigq,
- timr->it_process);
- }
- else {
- group:
- return send_group_sigqueue(timr->it_sigev_signo, timr->sigq,
- timr->it_process);
+ struct task_struct *leader;
+ int ret = send_sigqueue(timr->it_sigev_signo, timr->sigq,
+ timr->it_process);
+
+ if (likely(ret >= 0))
+ return ret;
+
+ timr->it_sigev_notify = SIGEV_SIGNAL;
+ leader = timr->it_process->group_leader;
+ put_task_struct(timr->it_process);
+ timr->it_process = leader;
}
+
+ return send_group_sigqueue(timr->it_sigev_signo, timr->sigq,
+ timr->it_process);
}
EXPORT_SYMBOL_GPL(posix_timer_event);
-
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/
open("foo", 3)
Linus et Al, Access mode of 3 is undocumented but it does do something halfway sane on all linuxes (checked back to 2.0.X). The open requires both read and write permission to succeed, but the resulting file descriptor can neither be read nor written. The responsible code in filp_open() is this: namei_flags = flags; if ((namei_flags+1) & O_ACCMODE) namei_flags++; /* ... */ error = open_namei(filename, namei_flags, mode, &nd); if (!error) return dentry_open(nd.dentry, nd.mnt, flags); And in dentry_open(): f->f_mode = ((flags+1) & O_ACCMODE) | /* ... */ Note, that open_namei() is checking permissions, and dentry_open() sets f->f_mode, but calculates it differently. My question is: is this deliberate or accidental? Wouldn't it be more logical to not require any permission to open such file? Or is there some security concern with that? Thanks, Miklos - 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] fs/adfs/adfs.h: "extern inline" doesn't make sense
On Sat, Aug 20, 2005 at 01:44:43AM +0200, Adrian Bunk wrote: > "extern inline" doesn't make sense. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks Adrian - I've committed it to my tree. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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 2.6.13-rc6-rt9] PI aware dynamic priority adjustment
On Sat, 2005-08-20 at 18:10 +0400, Oleg Nesterov wrote:
> posix_timer_event() first checks that the thread (SIGEV_THREAD_ID
> case) does not have PF_EXITING flag, then it calls send_sigqueue()
> which locks task list. But if the thread exits in between the kernel
> will oops.
> posix_timer_event() runs under k_itimer.it_lock, but this does not
> help if that thread was not the only one in thread group, in this
> case we don't call exit_itimers().
I added exit_notify_itimers() for that case. It is synchronized vs.
posix_timer_event() via the timer lock and therefor protects against the
race described above.
It solves the problem for the only user of send_sigqueue for now, but I
think we should have a more general interface to such functionality to
allow simple usage.
tglx
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff -uprN --exclude-from=/usr/local/bin/diffit.exclude
linux-2.6.13-rc6/include/linux/sched.h
linux-2.6.13-rc6.work/include/linux/sched.h
--- linux-2.6.13-rc6/include/linux/sched.h 2005-08-13 12:25:56.0
+0200
+++ linux-2.6.13-rc6.work/include/linux/sched.h 2005-08-20 17:43:36.0
+0200
@@ -1051,6 +1051,7 @@ extern void __exit_signal(struct task_st
extern void exit_sighand(struct task_struct *);
extern void __exit_sighand(struct task_struct *);
extern void exit_itimers(struct signal_struct *);
+extern void exit_notify_itimers(struct signal_struct *);
extern NORET_TYPE void do_group_exit(int);
diff -uprN --exclude-from=/usr/local/bin/diffit.exclude
linux-2.6.13-rc6/kernel/posix-timers.c
linux-2.6.13-rc6.work/kernel/posix-timers.c
--- linux-2.6.13-rc6/kernel/posix-timers.c 2005-08-13 12:25:58.0
+0200
+++ linux-2.6.13-rc6.work/kernel/posix-timers.c 2005-08-20 17:43:36.0
+0200
@@ -1169,6 +1169,33 @@ void exit_itimers(struct signal_struct *
}
/*
+ * This is called by __exit_signal, when there are still references to
+ * the shared signal_struct
+ */
+void exit_notify_itimers(struct signal_struct *sig)
+{
+ struct k_itimer *timer;
+ struct list_head *tmp;
+ unsigned long flags;
+
+ list_for_each(tmp, &sig->posix_timers) {
+
+ timer = list_entry(tmp, struct k_itimer, list);
+
+ /* Protect against posix_timer_fn */
+ spin_lock_irqsave(&timer->it_lock, flags);
+ if (timer->it_process == current) {
+
+ if (timer->it_sigev_notify ==
(SIGEV_SIGNAL|SIGEV_THREAD_ID))
+ timer->it_sigev_notify = SIGEV_SIGNAL;
+
+ timer->it_process = timer->it_process->group_leader;
+ }
+ spin_lock_irqrestore(&timer->it_lock, flags);
+ }
+}
+
+/*
* And now for the "clock" calls
*
* These functions are called both from timer functions (with the timer
diff -uprN --exclude-from=/usr/local/bin/diffit.exclude
linux-2.6.13-rc6/kernel/signal.c linux-2.6.13-rc6.work/kernel/signal.c
--- linux-2.6.13-rc6/kernel/signal.c2005-08-13 12:25:58.0 +0200
+++ linux-2.6.13-rc6.work/kernel/signal.c 2005-08-20 17:57:46.0
+0200
@@ -390,6 +390,7 @@ void __exit_signal(struct task_struct *t
sig->nvcsw += tsk->nvcsw;
sig->nivcsw += tsk->nivcsw;
sig->sched_time += tsk->sched_time;
+ exit_notify_itimers(sig);
spin_unlock(&sighand->siglock);
sig = NULL; /* Marker for below. */
}
@@ -1381,13 +1382,12 @@ send_sigqueue(int sig, struct sigqueue *
int ret = 0;
/*
-* We need the tasklist lock even for the specific
-* thread case (when we don't need to follow the group
-* lists) in order to avoid races with "p->sighand"
-* going away or changing from under us.
+* No need to hold tasklist lock here.
+* posix_timer_event() is synchronized via
+* exit_itimers() and exit_notify_itimers() to
+* be protected against p->sighand == NULL
*/
BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
- read_lock(&tasklist_lock);
spin_lock_irqsave(&p->sighand->siglock, flags);
if (unlikely(!list_empty(&q->list))) {
@@ -1414,7 +1414,6 @@ send_sigqueue(int sig, struct sigqueue *
out:
spin_unlock_irqrestore(&p->sighand->siglock, flags);
- read_unlock(&tasklist_lock);
return(ret);
}
-
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 [i6300escb.c 2 bugs, little cleanup]
In i6300esb.c watchdog card driver were 2 bugs (misused pc_match_device
and pci_dev_put wasn't called in one error case) and one little cleanup
was done (long line was converted to a shorter one with using built-in
macro).
Generated in 2.6.13-rc6-mm1 kernel version.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
i6300esb.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/watchdog/i6300esb.c b/drivers/char/watchdog/i6300esb.c
--- a/drivers/char/watchdog/i6300esb.c
+++ b/drivers/char/watchdog/i6300esb.c
@@ -349,7 +349,7 @@ static struct notifier_block esb_notifie
* want to register another driver on the same PCI id.
*/
static struct pci_device_id esb_pci_tbl[] = {
-{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_9, PCI_ANY_ID,
PCI_ANY_ID, },
+{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_9), },
{ 0, }, /* End of list */
};
MODULE_DEVICE_TABLE (pci, esb_pci_tbl);
@@ -369,7 +369,7 @@ static unsigned char __init esb_getdevic
*/
for_each_pci_dev(dev)
-if (pci_match_device(esb_pci_tbl, dev)) {
+if (pci_match_id(esb_pci_tbl, dev)) {
esb_pci = dev;
break;
}
@@ -377,7 +377,7 @@ static unsigned char __init esb_getdevic
if (esb_pci) {
if (pci_enable_device(esb_pci)) {
printk (KERN_ERR PFX "failed to enable device\n");
- goto out;
+ goto err_devput;
}
if (pci_request_region(esb_pci, 0, ESB_MODULE_NAME)) {
@@ -429,9 +429,10 @@ err_release:
pci_release_region(esb_pci, 0);
err_disable:
pci_disable_device(esb_pci);
+err_devput:
pci_dev_put(esb_pci);
}
-out:
+
return 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: SATA status report updated
Hi Jeff, Jeff Garzik <[EMAIL PROTECTED]> writes: > Here is a list of problems with the patch. I'll paste this into the > bug as well: [Lot of interesting issues] > 8) The DMA pad code is very buggy. It uses the dma_map_single() to > map a buffer, but never synchronizes nor flushes the buffer. This can > and will lead to data corruption, particularly on x86-64 platform. That's very bad since the target platform for that chipset is able to support AMD64. :-( >From your comments I've learned that my patch (just the device ID) is too tiny and the SiS provided patch is doing too much things that it shouldn't do. How can we find a solution for that? Would it make sense that I try to find the "goods" in the SiS patch and merge them somehow in the actual kernel? But: What kernel shall I take to do that work? The latest development kernel, the kernel of my distribution (whatever this will be, sooner or later it has to work with all distributions) or just a kernel that is "close" to the patch from SiS, e.g. 2.6.10? As I mentioned before, getting hardware to try out patches wouldn't be that big deal since I'm located in a PC factory and I can get test machines if needed. What would be good tests to e.g. detect the problems that you mentioned above? Are there hardware specific tests for SATA hard disks around? I would be very interested in that since testing also under Linux will become daily work for me and my colleauges from the system test department. Best regards Rainer (posting from home) -- Please send NO spam to my mail addresses. - 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-rt9
Thomas Gleixner wrote: On Fri, 2005-08-19 at 15:13 -0700, Darren Hart wrote: I was trying to use another HRT clock source and couldn't get menuconfig to let me select acpi-pm-timer, turns out it has been disabled in arch/i386/Kconfig, but the description is still in the help... # config HIGH_RES_TIMER_ACPI_PM # bool "ACPI-pm-timer" Is the pm timer incompatible with the RT portion of this patch? The only timesource I came around to fixup is TSC in combination with PIT or preferred Local APIC. Add "lapic" to your kernel command line for UP boxen. Therefor it is disabled for now. I'm looking into getting HRT and RT booting on a SUMMIT NUMA machine (cyclone timer), but after s/error/warning/ in arch/i386/timers/timer.c for the HRT cyclone ifdef, I still get the following link error: It should be simple to fix this. Just not right now. I have no such box and restricted time resources. Can you test a patch when I find a slot? Absolutely. But of course you are heartely invited to fix it yourself :) As always :-) tglx Thanks for the response, I wanted to hear your take on this rather than making any assumptions as to the state of the patch. -- Darren Hart IBM Linux Technology Center Linux Kernel Team Phone: 503 578 3185 T/L: 775 3185 - 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/
Linux-2.4.31-hf4
Hello ! After having accumulated a few weeks delay, the fourth hotfix for kernel 2.4.31 is finally out. It was also the right time to release it now that the isofs and zlib stories came to an end. Because of the ZISOFS security fix, users of older -hf or plain 2.4.X should upgrade either to latest -hf or to 2.4.32-pre3. Other fixes are less important. As usual, I've also updated 2.4.29 and 2.4.30. So all 3 Kernels 2.4.29-hf14, 2.4.30-hf7 and 2.4.31-hf4 are available as individual, full, and incremental patches here: http://linux.exosec.net/kernel/2.4/2.4-hf/ The changelog is appended to this mail. I've built 2.4.31-hf4 with all modules, and nothing more yet, but Grant Coady will soon report the full build and run test here : http://bugsplatter.mine.nu/test/linux-2.4/ (warning! URL changed) Regards, Willy -- Changelog From 2.4.31-hf3 to 2.4.31-hf4 --- '+' = added ; '-' = removed - 2.4.31-zlib-security-bugs-1(Tim Yamin) + 2.4.31-zlib-security-bugs-2 (Tim Yamin, Sergey Vlasov) Reverted the Z_OK to Z_DATA_ERROR changes in inftrees.c (& PPC). + 2.4.31-zisofs-check-deflatebound-1(Linus Torvalds) [PATCH] PATCH: Fix outstanding gzip/zlib security issues Add fakey 'deflateBound()' function to the in-kernel zlib routines. It's not the real deflateBound() in newer zlib libraries, partly because the upcoming usage of it won't have the "stream" available, so we can't have the same interfaces anyway. Problem noted by Tim Yamin. + 2.4.31-nat-fix-memory-corruption-1 (Patrick McHardy) [NETFILTER]: Fix potential memory corruption in NAT code (aka memory NAT) + 2.4.31-isofs-option-parse-fix-1 (Horms + Andrey J.Melnikoff) Fix isofs option parser. If iocharset, map or session are matched, then none of the if or else if clauses under sbsector will match (that is none of these clauses match iocharset, map or session), and thus the else clause will be hit, and the function will return 1 without parsing any furhter options. Also fix gcc-3.4 warnings. + 2.4.31-netfilter-tcp-unclean-1.diff (Patrick McHardy) [NETFILTER]: Ignore PSH on SYN/ACK in ipt_unclean + 2.4.31-redblacktree-missing-returns-1 ([EMAIL PROTECTED]) [PATCH] fix RedBlackTree rb_next/rb_prev functions. I have found a bug in the source of rbtree.c file in /lib. In Kernel 2.6 it's ok, but 2.4.31 has this error. We try to use it with the jffs2 source code and only with this fix it works fine. + 2.4.31-alpha-cabriolet-needs-ns87312-1 (Bill Dupree) [PATCH] Fix Alpha AXP Cabriolet build. Alpha AXP Cabriolet build fails with unresolved reference to ns87312_enable_ide(). -- END -- - 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] ia64 cpuset + build_sched_domains() mangles structures
I've already sent this to the maintainers, and this is now being sent to a
larger community audience. I have fixed a problem with the ia64 version of
build_sched_domains(), but a similar fix still needs to be made to the
generic build_sched_domains() in kernel/sched.c.
The "dynamic sched domains" functionality has recently been merged into
2.6.13-rcN that sees the dynamic declaration of a cpu-exclusive (a.k.a.
"isolated") cpuset and rebuilds the CPU Scheduler sched domains and sched
groups to separate away the CPUs in this cpu-exclusive cpuset from the
remainder of the non-isolated CPUs. This allows the non-isolated CPUs to
completely ignore the isolated CPUs when doing load-balancing.
Unfortunately, build_sched_domains() expects that a sched domain will
include all the CPUs of each node in the domain, i.e., that no node will
belong in both an isolated cpuset and a non-isolated cpuset. Declaring
a cpuset that violates this presumption will produce flawed data
structures and will oops the kernel.
To trigger the problem (on a NUMA system with >1 CPUs per node):
cd /dev/cpuset
mkdir newcpuset
cd newcpuset
echo 0 >cpus
echo 0 >mems
echo 1 >cpu_exclusive
I have fixed this shortcoming for ia64 NUMA (with multiple CPUs per node).
A similar shortcoming exists in the generic build_sched_domains() (in
kernel/sched.c) for NUMA, and that needs to be fixed also. The fix involves
dynamically allocating sched_group_nodes[] and sched_group_allnodes[] for
each invocation of build_sched_domains(), rather than using global arrays
for these structures. Care must be taken to remember kmalloc() addresses
so that arch_destroy_sched_domains() can properly kfree() the new dynamic
structures.
This is a patch against 2.6.13-rc6.
Signed-off-by: John Hawkes <[EMAIL PROTECTED]>
Index: linux/arch/ia64/kernel/domain.c
===
--- linux.orig/arch/ia64/kernel/domain.c2005-08-19 08:54:00.0
-0700
+++ linux/arch/ia64/kernel/domain.c 2005-08-20 07:39:32.0 -0700
@@ -120,10 +120,10 @@
* gets dynamically allocated.
*/
static DEFINE_PER_CPU(struct sched_domain, node_domains);
-static struct sched_group *sched_group_nodes[MAX_NUMNODES];
+static struct sched_group **sched_group_nodes_bycpu[NR_CPUS];
static DEFINE_PER_CPU(struct sched_domain, allnodes_domains);
-static struct sched_group sched_group_allnodes[MAX_NUMNODES];
+static struct sched_group *sched_group_allnodes_bycpu[NR_CPUS];
static int cpu_to_allnodes_group(int cpu)
{
@@ -138,6 +138,21 @@
void build_sched_domains(const cpumask_t *cpu_map)
{
int i;
+#ifdef CONFIG_NUMA
+ struct sched_group **sched_group_nodes = NULL;
+ struct sched_group *sched_group_allnodes = NULL;
+
+ /*
+* Allocate the per-node list of sched groups
+*/
+ sched_group_nodes = kmalloc(sizeof(struct sched_group*)*MAX_NUMNODES,
+ GFP_ATOMIC);
+ if (!sched_group_nodes) {
+ printk(KERN_WARNING "Can not alloc sched group node list\n");
+ return;
+ }
+ sched_group_nodes_bycpu[first_cpu(*cpu_map)] = sched_group_nodes;
+#endif
/*
* Set up domains for cpus specified by the cpu_map.
@@ -150,8 +165,21 @@
cpus_and(nodemask, nodemask, *cpu_map);
#ifdef CONFIG_NUMA
- if (num_online_cpus()
+ if (cpus_weight(*cpu_map)
> SD_NODES_PER_DOMAIN*cpus_weight(nodemask)) {
+ if (!sched_group_allnodes) {
+ sched_group_allnodes
+ = kmalloc(sizeof(struct sched_group)
+ * MAX_NUMNODES,
+ GFP_KERNEL);
+ if (!sched_group_allnodes) {
+ printk(KERN_WARNING
+ "Can not alloc allnodes sched group\n");
+ break;
+ }
+ sched_group_allnodes_bycpu[i]
+ = sched_group_allnodes;
+ }
sd = &per_cpu(allnodes_domains, i);
*sd = SD_ALLNODES_INIT;
sd->span = *cpu_map;
@@ -214,8 +242,9 @@
}
#ifdef CONFIG_NUMA
- init_sched_build_groups(sched_group_allnodes, *cpu_map,
- &cpu_to_allnodes_group);
+ if (sched_group_allnodes)
+ init_sched_build_groups(sched_group_allnodes, *cpu_map,
+ &cpu_to_allnodes_group);
for (i = 0; i < MAX_NUMNODES; i++) {
/* Set up node groups */
@@ -226,8 +255,10 @@
int j;
cpus_and(nodemask, nodemask, *cpu_m
Re: 2.6.13-rc6-mm1
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Friday, August 19, 2005 04:33:31 -0700): > > 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. Get a couple of debug warnings as you mention ... but then it panics. scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs Vendor: IBM Model: GNHv1 S2 Rev: 0 Type: Processor ANSI SCSI revision: 02 target1:0:9: Beginning Domain Validation target1:0:9: Ending Domain Validation Vendor: IBM-ESXS Model: DTN036C1UCDY10F Rev: S25J Type: Direct-Access ANSI SCSI revision: 03 scsi1:A:12:0: Tagged Queuing enabled. Depth 253 target1:0:12: Beginning Domain Validation target1:0:12: wide asynchronous. target1:0:12: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127) target1:0:12: Ending Domain Validation Vendor: IBM-ESXS Model: DTN036C1UCDY10F Rev: S25J Type: Direct-Access ANSI SCSI revision: 03 scsi1:A:13:0: Tagged Queuing enabled. Depth 253 target1:0:13: Beginning Domain Validation target1:0:13: wide asynchronous. target1:0:13: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127) target1:0:13: Ending Domain Validation scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scheduling while atomic: swapper/0x0100/0 [] schedule+0x45/0x724 [] __wake_up+0x31/0x3c [] dcache_shrinker_del+0x2e/0x38 [] dput_recursive+0x232/0x270 [] dput_recursive+0x265/0x270 [] __down+0x7f/0x108 [] default_wake_function+0x0/0x1c [] __down_failed+0x7/0xc [] .text.lock.attribute_container+0x8b/0xc1 [] transport_remove_device+0xf/0x14 [] transport_remove_classdev+0x0/0x58 [] scsi_target_reap+0x86/0xb4 [] scsi_device_dev_release+0x134/0x15c [] device_release+0x14/0x4c [] kobject_cleanup+0x47/0x6c [] kobject_release+0x0/0x14 [] kobject_release+0xd/0x14 [] kref_put+0x79/0x89 [] kobject_put+0x16/0x1c [] kobject_release+0x0/0x14 [] put_device+0x11/0x18 [] scsi_put_command+0xa5/0xb0 [] scsi_next_command+0x11/0x1c [] scsi_end_request+0xa9/0xb4 [] scsi_io_completion+0x489/0x494 [] scsi_generic_done+0x32/0x38 [] scsi_finish_command+0xa0/0xa8 [] scsi_softirq+0x139/0x154 [] __do_softirq+0x8d/0x100 [] do_softirq+0x2f/0x34 [] irq_exit+0x34/0x38 [] do_IRQ+0x20/0x28 [] common_interrupt+0x1a/0x20 [] default_idle+0x0/0x2c [] default_idle+0x23/0x2c [] cpu_idle+0x7b/0x8c [] rest_init+0x28/0x2c [] start_kernel+0x197/0x19c scheduling while atomic: swapper/0x0100/0 [] schedule+0x45/0x724 [] default_wake_function+0x17/0x1c [] __wake_up_common+0x37/0x50 [] __wake_up+0x31/0x3c [] wait_for_completion+0x90/0xe8 [] default_wake_function+0x0/0x1c [] default_wake_function+0x0/0x1c [] call_usermodehelper_keys+0x144/0x15a [] __call_usermodehelper+0x0/0x4c [] __call_usermodehelper+0x0/0x4c [] kobject_hotplug+0x255/0x280 [] class_device_del+0x8d/0xa8 [] attribute_container_class_device_del+0x11/0x18 [] transport_remove_classdev+0x4f/0x58 [] attribute_container_device_trigger+0x7f/0xb8 [] transport_remove_device+0xf/0x14 [] transport_remove_classdev+0x0/0x58 [] scsi_target_reap+0x86/0xb4 [] scsi_device_dev_release+0x134/0x15c [] device_release+0x14/0x4c [] kobject_cleanup+0x47/0x6c [] kobject_release+0x0/0x14 [] kobject_release+0xd/0x14 [] kref_put+0x79/0x89 [] kobject_put+0x16/0x1c [] kobject_release+0x0/0x14 [] put_device+0x11/0x18 [] scsi_put_command+0xa5/0xb0 [] scsi_next_command+0x11/0x1c [] scsi_end_request+0xa9/0xb4 [] scsi_io_completion+0x489/0x494 [] scsi_generic_done+0x32/0x38 [] scsi_finish_command+0xa0/0xa8 [] scsi_softirq+0x139/0x154 [] __do_softirq+0x8d/0x100 [] do_softirq+0x2f/0x34 [] irq_exit+0x34/0x38 [] do_IRQ+0x20/0x28 [] common_interrupt+0x1a/0x20 [] default_idle+0x0/0x2c [] default_idle+0x23/0x2c [] cpu_idle+0x7b/0x8c [] rest_init+0x28/0x2c [] start_kernel+0x197/0x19c Unable to handle kernel NULL pointer dereference at virtual address printing eip: c0263cf2 *pde = 0042c001 *pte = Oops: [#1] SMP last sysfs file: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010282 (2.6.13-rc6-mm1-autokern1) EIP is at scsi_run_queue+0xe/0xb4 eax: d777ce30 ebx: d777ce30 ecx: 0282 edx: d6c4cc00 esi: d777ce30 edi: ebp: 0246 esp: c03dde98 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c03dc000 task=c0373be0) Stack: d777ce30 d777ce30 d76fb500 0246 c0263dfb d777ce30
CLOCK_TICK_RATE for slowing down the system clock?
For my own purpose I would like to slow down the clock maintained by the Linux kernel. I want to simulate 10Gb/s network connection with roughly 1 TCP connections. For this I want to use two (perhaps dual processor if need be) PC computers connected with 1Gb/s Ethernet. To achieve this goal I need to trick the Linux TCP implementation that it's running on a 10x faster setup. Therefore I have the following idea, which I partially tested. So far I have not tested the TCP performance, but only some general system performance. I did some simple tests with Linux 2.6.12 on my laptop with Pentium 4, 2.8 GHz, no hyperthreading. The idea is to slow down 10 times the clock maintained by the Linux kernel. Software that relies on the system clock (such as the TCP Linux kernel implementation, and other software such as the top command) should be tricked to think that it runs on a 10 times faster computer with a 10Gb/s link. The simplest hack I have came up with to slow down the clock is to compile the kernel with a different frequency of the hardware clock as defined in the linux-2.6.12/include/asm-i386/timex.h file: # define CLOCK_TICK_RATE 1193182 /* Underlying HZ */ I multiplied this value by 10: # define CLOCK_TICK_RATE 11931820 /* Underlying HZ */ I recompiled and installed the new kernel. Once we are running (with the noapic option at boot time) the new kernel, a simple way of making sure the system clock is running slower is to use the date command and see how slow the time is passing. And yes, the system clock was running 10 times slower. But unfortunately, not only the system clock was running slower... Some tasks were running slower. Linux would boot 5 times slower, and it would shut down 5 times slower, which might be caused by the sleep and usleep commands used in the /etc/init.d scripts. Naturally, I expected some software to run 10 times slower, such as the top command, which is supposed to report results every 3 seconds. My simple test was to copy a 1GB file between two disc partitions. On a regular kernel I ran: ~ >time cp 1GB /jaguar/ijs/ real1m50.529s user0m0.185s sys 0m6.869s Then on the slow kernel I ran: ~ >time cp 1GB /jaguar/ijs/ real0m10.444s user0m0.013s sys 0m0.578s Sometimes I had an impression that on the slow kernel some things worked slightly slower, such as logging in. Overall, however, it seems that the system was performing 10 times faster when measured with the slowed down system clock. Therefore my simple tests give me some courage to pursue this path. But before I start working on this and spend more time on testing and implementing my software, I want to make sure that I hope for too much and that my plan is viable. MY QUESTION IS: Are there some pitfalls or problems which I failed to notice? Thanks for reading! Best, Irek - 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 2.6.13-rc6-rt9] PI aware dynamic priority adjustment
Thomas Gleixner wrote: > > send_sigqueue is called from posix_timer_fn() and acquires > tasklist_lock, which makes no sense to me. > > send_sigqueue()s (l)onl(e)y user is the posix_timer function > (posix_timer_fn(), calling posix_timer_event()). > > Each posix timer blocks the task from vanishing away by > get_task_struct(), which is protected by the held tasklist_lock. > > The task can neither go away nor the signal handler can change until > put_task_struct() is called inside release_posix_timer(), which removes > any chance to do an invalid access to either task or sighand because the > relevant timer is deleted before the call to put_task_struct(). Also > this call is protected by tasklist_lock(). Yes, the task_struct can't go away, but if process exited this task_struct is just chunk of garbage. I think the intent was to protect against this case. However, I agree with you, locking the tasklist_lock can't help, and the code is wrong. posix_timer_event() first checks that the thread (SIGEV_THREAD_ID case) does not have PF_EXITING flag, then it calls send_sigqueue() which locks task list. But if the thread exits in between the kernel will oops. posix_timer_event() runs under k_itimer.it_lock, but this does not help if that thread was not the only one in thread group, in this case we don't call exit_itimers(). The comment is wrong too. ->sighand can't change, we are clearing posix timer on exec, and tasklist can't prevent ->sighand from going away.. Ingo, Roland, George, am I wrong? Oleg. - 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: sched_yield() makes OpenLDAP slow
Howard Chu <[EMAIL PROTECTED]> writes: > In this specific example, we use whatever > BerkeleyDB provides and we're certainly not about to write our own > transactional embedded database engine just for this. BerkeleyDB is free software after all that comes with source code. Surely it can be fixed without rewriting it from scratch. Has anybody contacted the Sleepycat people with a description of the problem yet? -Andi - 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, 2005-08-19 at 18:36 -0700, Andrew Morton wrote: > Reuben Farrelly <[EMAIL PROTECTED]> wrote: > > > > ... > > >> 4. PAM is complaining about "PAM audit_open() failed: Protocol not suppor > > >> ted" and I can't log in as any user including root. I would have picked > > >> this > > >> was a userspace problem, but it doesn't break with -rc5-mm1, yet > > >> reproduceably > > >> breaks with -rc6-mm1. Weird. > > > > > > hm. How come you're able to use the machine then? > > > > Machine was booting up ok, and things were being written to syslog. > > Rebooted > > into -rc5-mm1 to investigate, and of course could boot into rc6-mm1 in > > single > > user mode, test and bring services up one by one from there. Having two > > boxes > > helped too. > > > > > Is it possible to get an strace of this failure somehow? > > > > Not sure if this is needed anymore, as I found that the problem goes away > > when > > I compile in kernel auditing. This not required for -rc5-mm1. Is that > > change > > intended? > > > > Sounds wrong to me, especially if 2.6.13-rc6 doesn't do that. Hm. It sounds like you'd configured PAM to require the pam_loginuid module even though you didn't have auditing enabled in your kernel. That seems strange and wrong to me, and _is_ a userspace problem. I'd also agree that it shouldn't have changed with the new kernel though -- and I can't think of anything I changed recently which would have that effect. An strace would still be useful. Can you double-check that you didn't have auditing enabled in your older, working kernel? -- dwmw2 - 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: sched_yield() makes OpenLDAP slow
Howard Chu writes:
> Nikita Danilov wrote:
[...]
>
> > What prevents transaction monitor from using, say, condition
> > variables to "yield cpu"? That would have an additional advantage of
> > blocking thread precisely until specific event occurs, instead of
> > blocking for some vague indeterminate load and platform dependent
> > amount of time.
>
> Condition variables offer no control over which thread is waken up.
When only one thread waits on a condition variable, which is exactly a
scenario involved, --sorry if I weren't clear enough-- condition signal
provides precise control over which thread is woken up.
> We're wandering into the design of the SleepyCat BerkeleyDB library
> here, and we don't exert any control over that either. BerkeleyDB
> doesn't appear to use pthread condition variables; it seems to construct
> its own synchronization mechanisms on top of mutexes (and yield calls).
That returns us to the core of the problem: sched_yield() is used to
implement a synchronization primitive and non-portable assumptions are
made about its behavior: SUS defines that after sched_yield() thread
ceases to run on the CPU "until it again becomes the head of its thread
list", and "thread list" discipline is only defined for real-time
scheduling policies. E.g.,
int sched_yield(void)
{
return 0;
}
and
int sched_yield(void)
{
sleep(100);
return 0;
}
are both valid sched_yield() implementation for non-rt (SCHED_OTHER)
threads.
Nikita.
-
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 bug: Bad page state: related to generic symlink code and mmap
Hi Linus, On Fri, 19 Aug 2005, Linus Torvalds wrote: > On Fri, 19 Aug 2005, Anton Altaparmakov wrote: > > Yes, sure. I have applied your patch to our 2.6.11.4 tree (with the one > > liner change I emailed you just now) and have kicked off a compile. > > Actually, hold on. The original patch had another problem: it returned an > uninitialized "page" pointer when page_getlink() failed. I copied the fix to that problem from your new patch by hand and recompiled the kernel (that way I didn't have to rebuild the modules again). Note I did not apply any of the fs specific changes. I only did the VFS part of your patch that was actually necessary. And I reverted my ncpfs fix so it is now again using the vfs supplied symlink helpers. Having booted the new kernel and trying nautilus it worked fine accessing the same symlink that failed before, so your patch fixes the ncpfs problem as one would expect but always good to be sure. (-: btw. It may be an idea to switch smbfs to use the fixed generic symlink functions, too, so it benefits from symlink caching... Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - 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 2.6-mm] tms380tr: remove prototypes in Space.c
On Fri, Aug 19, 2005 at 03:07:09AM -0400, Jeff Garzik wrote: > these two patches look OK to me, but didn't apply. > > Can you please resend, according to > > http://linux.yyz.us/patch-format.html > > ? It seems the second of Jochen's patches does no longer apply (at least against the latest -mm), but what was wrong with the format of his patches? > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 2.6.13-rc6] docs: fix misinformation about overcommit_memory
On Fri, Aug 19, 2005 at 11:14:39PM -0400, Chuck Ebbert wrote: > Someone complained about the docs for vm_overcommit_memory being wrong. > This patch copies the text from the vm documentation into procfs. > Please apply. >... Do we really need two copies of the same text? Couldn't you instead write some kind of "please look at Documentation/vm/overcommit-accounting"? > Chuck cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [RFC][PATCH] Rename PageChecked as PageMiscFS
Daniel Phillips <[EMAIL PROTECTED]> wrote: > Biased. Fs is a mixed case acronym, nuff said. But I'm still right:-) David - 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 2/2] external interrupts: IOC4 driver
> +config EXTINT_SGI_IOC4
> + tristate "Device driver for SGI IOC4 external interrupts"
> + depends on (IA64_GENERIC || IA64_SGI_SN2) && EXTINT && BLK_DEV_SGIIOC4
Is the ioc4 core abstraction config symbol really BLK_DEV_SGIIOC4?
That probably wants fixing in a separate patch.
> + This option enables support for the external interrupt ingest
> + and generation capabilities of SGI IOC4 IO controllers. If
> + you have an SGI Altix with an IOC4 based IO card, say Y.
> + Otherwise, say N.
Is there any Altix without an ioc4?
> + */
> +static ssize_t ioc4_extint_get_modelist(struct extint_device *ed, char *buf)
> {
opening brace on a separate line please.
> +#if PAGE_SIZE <= IOC4_A_INT_OUT_LENGTH
> + /* Only set up INT_OUT register alias page if the system page size
> + * is equal to or less than the register alias page size. Otherwise
> + * the user would have access to registers other than INT_OUT.
> + */
> + a_int_out = pci_resource_start(ied->idd->idd_pdev, 0) +
> + IOC4_A_INT_OUT_OFFSET;
> + if (!a_int_out) {
> + printk(KERN_WARNING
> +"%s: Unable to get IOC4 int_out alias mapping "
> +"for pci_dev 0x%p.\n", __FUNCTION__, ied->idd->idd_pdev);
> + goto skip_alias;
> + }
> + if (!request_region(a_int_out, IOC4_A_INT_OUT_LENGTH,
> + "ioc4_a_int_out")) {
This looks rather bad. So the driver silently has less functionality
when using a bigger page size?
> + /* Enable interrupt input */
> + ret = ioc4_extint_input_enable(ied);
> + if (ret)
> + goto out_enable;
> +
> + return 0;
> +
> +out_enable:
> + extint_device_unregister(idd->idd_extint_data);
> +out_register:
> + ioc4_extint_device_destroy(ied);
> +out_device:
> + ioc4_extint_input_teardown(ied);
> + ioc4_extint_output_teardown(ied);
> + kfree(ied);
> +out:
> + return ret;
> +}
> +
> +static int ioc4_extint_remove(struct ioc4_driver_data *idd)
> +{
> + struct extint_device *ed = idd->idd_extint_data;
> + struct ioc4_extint_device *ied;
> +
> + /* If probe failed, avoid trying to remove */
> + if (ed)
> + ied = extint_get_devdata(ed);
> + else
> + return -ENXIO;
This should at lease be written:
if (!ed)
return -ENXIO;
ied = extint_get_devdata(ed);
but I don't understand how it can happen anyway. ->remove shoould
never be called unless ->probe initialized the device fully and
returned 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: lost ticks and Hangcheck
Please make sure this issue is reproducible without any binary only drivers. I uninstalled the NVIDIA drivers and tried again with the nv x.org driver. Same problem. I also tried remaining in text mode (with no NVIDIA drivers loaded). Same problem. In both cases it occurs when I start seriously loading the CPU. One thing that may be of interest is that the message in dmesg is different if I'm in text mode vs. x.org. If I'm in text mode the message is: Losing some ticks... checking if CPU frequency changed. If I'm running x.org then I get warning: many lost ticks. Your time source seems to be instable or some driver is hogging interupts rip default_idle+0x20/0x30 OK, I'll open a bug report in bugzilla. I don't think this is the same as bug #3341. My clock comes up normal 100% of the time on boot up. Things only go awry when I start putting a load on the CPU. Thanks very much for your help, and please cc. me if you find anything out since I'm not a regular subscriber. Nathan - 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 1/2] external interrupts: abstraction layer
> diff --git a/drivers/char/extint.c b/drivers/char/extint.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/char/extint.c
> @@ -0,0 +1,673 @@
> +/*
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 2005 Silicon Graphics, Inc. All Rights Reserved.
> + */
> +
> +/* This file provides an abstraction for lowlevel external interrupt
> + * operation.
> + *
> + * External interrupts are hardware mechanisms to generate or ingest
> + * a simple interrupt signal.
> + *
> + * Generation typically involves driving an output circuit voltage
> + * level, with a variety of single or recurring waveforms (e.g.
> + * a one-shot pulse, a square wave, etc.) The repetition period
> + * for recurring waveforms can be set within hardware restrictions.
> + *
> + * Ingest typically involves responding to an input circuit voltage
> + * level or transition. Multiple input sources may be available.
> + *
> + * 2005.07.27Brent Casavant <[EMAIL PROTECTED]> Initial code
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * Module global data *
> + **/
> +
> +/* Device numbers */
> +#define EXTINT_NUMDEVS 255 /* Number of minor devices to reserve */
> +static dev_t firstdev; /* Start of dynamic range */
> +static dev_t nextdev;/* Next number to assign */
> +static DEFINE_SPINLOCK(nextdev_lock);
> +
> +/* Device status. Controls whether new callouts can be registered. */
> +enum extint_state {
> + EXTINT_COMING,
> + EXTINT_ALIVE,
> + EXTINT_GOING,
> + EXTINT_DEAD
> +};
> +
> +/**
> + * Abstracted devices *
> + **/
> +
> +static struct page *extint_counter_vma_nopage(struct vm_area_struct *vma,
> + unsigned long address, int *type)
> +{
> + struct extint_device *ed = vma->vm_private_data;
> + struct page *page;
> +
> + /* Only a single page is ever mapped */
> + if (address >= vma->vm_start + PAGE_SIZE)
> + return NOPAGE_SIGBUS;
> +
> + /* virt_to_page can be expensive, but this is executed
> + * only once each time the counter page is mapped.
> + */
> + page = virt_to_page(ed->counter_page);
I think you should store both the struct page pointer and the virtual
address in struct extint_device. This avoids doing the virt_to_page
at every pagefauls. It's also cleaner as you an juse use alloc_page()
and the page_address() to get the kernel virtual address.
> + get_page(page);
> +
> + if (type)
> + *type = VM_FAULT_MINOR;
> +
> + return page;
> +}
> +
> +static struct vm_operations_struct extint_counter_vm_ops = {
> + .nopage = extint_counter_vma_nopage,
> +};
> +
> +static int extint_counter_open(struct inode *inode, struct file *filp)
> +{
> + struct extint_device *ed = file_to_extint_device(filp);
you don't need the file but just the inode (strictly speaking the cdev),
and doing this based on the file is rather confusing to the reader because
the struct file passed to ->open has just been allocated.
> +
> + /* Counter is always read-only */
> + if (filp->f_mode & FMODE_WRITE)
> + return -EPERM;
> +
> + /* Prevent low-level module from unloading while
> + * corresponding abstracted device is open
> + */
> + if (!try_module_get(ed->props->owner))
> + return -ENXIO;
> +
> + /* Snapshot initial value, for later use by poll */
> + filp->private_data = (void *)*ed->counter_page;
What about storing the whole extint_device pointer in file->private_data?
That's get rid of a lot of casting and would make possible future additions
easier.
> +
> + return 0;
> +}
> +
> +static int extint_counter_release(struct inode *inode, struct file *filp)
> +{
> + struct extint_device *ed = file_to_extint_device(filp);
> +
> + /* Allow low-level module to unload now that the
> + * corresponding abstracted device is really closed.
> + */
> + module_put(ed->props->owner);
> +
> + return 0;
> +}
> +
> +static ssize_t
> +extint_counter_read(struct file *filp, char *buff, size_t count, loff_t *
> offp)
> +{
> + struct extint_device *ed = file_to_extint_device(filp);
> + char outbuff[21]; /* 20 chars for value of 2^64, plus \0 */
> +
> + /* Snapshot last value read, for later use by poll */
> + memset(outbuff, 0, 21);
> + filp->private_data = (void *)*ed->counter_page;
> + snprintf(outbuff, 21, "%ld", (unsigned long)filp->private_data);
> + outbuff[20] = '\0';
> +
> + return simple_read_from_buffer(buff, count, offp, outbuff,
> +strlen(outbuff));
> +}
> +
> +stati
Re: [Documentation] Use doxygen or another tool to generate a documentation ?
Le Saturday 20 August 2005 a 09:08, Sam Ravnborg ecrivait: > > > > Ok, with scripts/kernel-doc, I can produce some html files containing > > the functions' documentation. > > > > make pdfdocs or others targets don't work :| > > You probarly need some additional packages. > But it's not easy to help you with no log of what happened. Yes, sorry, Kernel : 2.6.12 from the git repository of Linus. In make_docs.log.tar.bz2, you can find log files from make htmldocs, make psdocs and make pdfdocs. Thanks, Stephane -- Stephane Wirtel <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> make_docs.log.tar.bz2 Description: Binary data
Re: [2.6 patch] simplify SOFTWARE_SUSPEND dependencies
Hi! > This patch expresses the same dependencies in a more simple way. I have this currently in my tree: depends on PM && SWAP && (X86 || ((FVR || PPC32) && !SMP)) (I really want to remove experimental), but it is not urgent enough to push heavily. Pavel > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- linux-2.6.13-rc6-mm1-full/kernel/power/Kconfig.old2005-08-20 > 06:02:49.0 +0200 > +++ linux-2.6.13-rc6-mm1-full/kernel/power/Kconfig2005-08-20 > 06:03:13.0 +0200 > @@ -28,7 +28,7 @@ > > config SOFTWARE_SUSPEND > bool "Software Suspend" > - depends on EXPERIMENTAL && PM && SWAP && ((X86 && SMP) || ((FVR || > PPC32 || X86) && !SMP)) > + depends on EXPERIMENTAL && PM && SWAP && (X86 || ((FVR || PPC32) && > !SMP)) > ---help--- > Enable the possibility of suspending the machine. > It doesn't need APM. > -- if you have sharp zaurus hardware you don't need... you know my 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 PATCH] SLAB : removes local_irq_save()/local_irq_restore() pair in ksize()
This patch removes unnecessary critical section in ksize() function, as cli/sti
are rather expensive on modern CPUS.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
diff -Nru linux-2.6.13-rc6-ed/mm/slab.c linux-2.6.13-rc6/mm/slab.c
--- linux-2.6.13-rc6-ed/mm/slab.c 2005-08-20 09:22:29.0 +0200
+++ linux-2.6.13-rc6/mm/slab.c 2005-08-20 09:39:42.0 +0200
@@ -3080,10 +3080,8 @@
unsigned int size = 0;
if (likely(objp != NULL)) {
- local_irq_save(flags);
c = GET_PAGE_CACHE(virt_to_page(objp));
size = kmem_cache_size(c);
- local_irq_restore(flags);
}
return size;
Re: [Documentation] Use doxygen or another tool to generate a documentation ?
> > Ok, with scripts/kernel-doc, I can produce some html files containing > the functions' documentation. > > make pdfdocs or others targets don't work :| You probarly need some additional packages. But it's not easy to help you with no log of what happened. Sam - 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] Permissions don't stick on ConfigFS attributes
On Saturday 20 August 2005 16:31, Joel Becker wrote:
> On Fri, Aug 19, 2005 at 08:01:17PM -0700, Greg KH wrote:
> > The recent changes to sysfs should be ported to configfs to do this.
>
> Yeah, I've been meaning to do something, and resusing code is
> always a good plan.
Ending up with the same code in core kernel in two different places is always
a bad plan. Oh man. Just look at these two bodies of code, configfs is
mostly just large tracts that are identical to sysfs except for name changes.
Listen to what the code is trying to tell you!
SysFS:
struct kobject {
const char * k_name;
charname[KOBJ_NAME_LEN];
struct kref kref;
struct list_headentry;
struct kobject * parent;
struct kset * kset;
struct kobj_type* ktype;
struct dentry * dentry;
};
ConfigFS:
struct config_item {
char*ci_name;
charci_namebuf[CONFIGFS_ITEM_NAME_LEN];
struct kref ci_kref;
struct list_headci_entry;
struct config_item *ci_parent;
struct config_group *ci_group;
struct config_item_type *ci_type;
struct dentry *ci_dentry;
};
Big difference, huh?
As designer of configfs, could you please offer your take on why it cannot be
rolled back into sysfs, considering that it is mostly identical already?
Regards,
Daniel
-
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 2.6.13-rc6-rt9] PI aware dynamic priority adjustment
Thomas Gleixner wrote: ~ 2. Drift of cyclic timers (armed by set_timer()): Due to rounding errors and the drift adjustment code, the fixed increment which is precalculated when the timer is set up and added on rearm, I see creeping deviation from the timeline. I have a patch lined up to base the rearm on human (nsac) units, so this effect will go away. But this is waste of time until (1.) is not solved. George ??? Could I (we) see what you have in mind? -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - 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 2.6.13-rc6-rt9] PI aware dynamic priority adjustment
Thomas Gleixner wrote: George, On Fri, 2005-08-19 at 17:19 -0700, George Anzinger wrote: 2. Drift of cyclic timers (armed by set_timer()): Due to rounding errors and the drift adjustment code, the fixed increment which is precalculated when the timer is set up and added on rearm, I see creeping deviation from the timeline. I have a patch lined up to base the rearm on human (nsac) units, so this effect will go away. But this is waste of time until (1.) is not solved. George ??? Could I (we) see what you have in mind? Nothing which applies clean at the moment and I have no access to the box where the patch floats around. It's simply explained. Current code: set_timer() calc interval->jiffies / interval->arch_cycles; based on it.interval rearm() timer->expires += interval->jiffies; timer->arch_cycle_expires += interval->arch_cycles; normalize(timer); Patched code: set_timer() timer.interval = it.interval; timer.next_expire = it.value; both stored as timespec rearm() next_expire += interval; calc timer->expires/arch_cycle_expires; So on each rearm we eliminate the rounding errors and take the drift adjustment into account. It adds some calculation overhead to each rearm, but I think the standard was written to eliminate the need for this. The notion is that we have a resolution which we use in the calculations so while there may be drift WRT his request, there should be no drift WRT the requested value rounded up to the next resolution. Still, if we can't keep that resolution in arch_cycles... On another issue along this line, I have been thinking of changing the x86 TSC arch cycle size to 1ns. (NOT the resolution, the units for the arch cycle.) The reason to do this is to correctly track changes in cpu frequency as it is today, we would need to track down and update all pending HR timers when ever the frequency changed. By using a common unit all we need to do is change the conversion constants (well I guess they would not be constants any more :). I REALLY don't want to do this as it does add conversion overhead, but I can not think of another clean way to track TSC frequency changes. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - 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/
