Re: 2.6.13-rc6-rt6
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > Since the change made raw_local_save_flags the same for both > PREEMPT_RT and !PREEMPT_RT, I moved it out of the #ifdef altogether. > The __raw_local_save_flags already does the type checking (at least > for intel). ok, i've applied this one. Indeed it's pointless to trace the local_save_flags API. Ingo - 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: [UPDATE PATCH] push rounding up of relative request to schedule_timeout()
On 16.08.2005 [17:39:11 -0700], George Anzinger wrote: > Nishanth Aravamudan wrote: > >On 04.08.2005 [09:45:55 -0700], George Anzinger wrote: > > > >>Uh... PLEASE tell me you are NOT changing timespec_to_jiffies() (and > >>timeval_to_jiffies() to add 1. This is NOT the right thing to do. For > >>repeating times (see setitimer code) we need the actual time as we KNOW > >>where the jiffies edge is in the repeating case. The +1 is needed ONLY > >>for the initial time, not the repeating time. > >> > >> > >>See: > >>http://marc.theaimsgroup.com/?l=linux-kernel=112208357906156=2 > > > > > >I followed that thread, George, but I think it's a different case with > >schedule_timeout() [maybe this indicates drivers/other users should > >maybe be using itimers, but I'll get to that in a sec]. > > I think I miss understood back then :). Ok, no problem. I was just thinking today about all the issues that were borught up... I really appreciate your feedback. > > > >With schedule_timeout(), we are just given a relative jiffies value. We > >have no context as to which task is requesting the delay, per se, > >meaning we don't (can't) know from the interface whether this is the > >first delay in a sequence, or a brand new one, without changing all > >users to have some sort of control structure. The callers of > >schedule_timeout() don't even get a pointer to the timer added > >internally. > > > >So, adding 1 to all sleeps seems like it might be reasonable, as looping > >sleeps probably need to use a different interface. I had worked a bit > >ago on something like poll_event() with the kernel-janitors group, which > >would abstract out the repeated sleeps. Basically wait_event() without > >wait-queues... Maybe we could make such an interface just use itimers? > >I've attached my old patch for poll_event(), just for reference. > > I think not. itimers is really pointed at a particular system call and > has resources in the task structure to do it. These would be hard to > share... Ok, I wasn't sure about that -- I'm not too familiar with the itimer code (maybe I'll take a look at it soon :) ) > >My point, I guess, is that in the schedule_timeout() case, we don't know > >where the jiffies edge is, as we either expire or receive a wait-queue > >event/signal, we never mod_timer() the internal timer... So we have to > >assume that we need to sleep the request. But maybe Roman's idea of > >sleeping a certain number of jiffy edges is sufficient. I am not yet > >convinced driver authors want/need such an interface, though, still > >thinking it over. > > IMNSHO we should not get too parental with kernel only interfaces. > Adding 1 is easy enough for the caller and even easier to explain in the > instructions (i.e. this call sleeps for X jiffies edges). This allows > the caller to do more if needed and, should he ever just want to sync to > the next jiffie he does not have to deal with backing out that +1. I don't want to be too parental either, but I also am trying to avoid code duplication. Lots of drivers basically do something like poll_event() does (or could do with some changes), i.e. looping a constant amount multiple times, checking something every so often. The patch was just a thought, though. I will keep evaluating drivers and see if it's a useful interface to have eventually. I guess I'm just concerned with making an unintuitive interface. As was brought up at OLS, drivers are a major source of bugs/buggy code. The simpler, more useful we can make interfaces, the better, I think. I'm not claiming you disagree, I just want to make my own motives clear. While fixing up the schedule_timeout() comment would make it clear what schedule_timeout() achieves, I'm not sure how useful such an interface is, if every caller adds 1 :) I need to mull it over, though... Lots to consider. I also, of course, want to stay flexible for the reasons you mention (letting the driver adjust the timeout as they expect to). Thanks, Nish - 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: compiling only one module in kernel version 2.6?
On Wed, 2005-08-17 at 01:48 -0400, Steven Rostedt wrote: > On Tue, 2005-08-16 at 22:41 -0700, Randy.Dunlap wrote: > > > > Sam only added make .ko build support very recently, > > so it could easily depend on what kernel verison Fong is using. > > That could very well explain it. I'm doing this on 2.6.13-rc6-rt6 > (2.6.13-rc6 with Ingo's rt6 patch applied). So I really do have a > recent kernel. > I just did this on a 2.6.9 vanilla kernel, and it still worked. How "recent" did Sam do this? -- 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/
Re: [2.6.13-rc6-latest] SCSI disk registration msgs repeat themselves
On Tue, 16 Aug 2005 21:39:33 -0700, Patrick Mansfield <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 16, 2005 at 11:01:30PM -0400, Chuck Ebbert wrote:
> > I just added some usb-storage devices to my system and got the below.
> > Why do the first four lines repeat for each device? (Not sure if
> > this is a SCSI or USB problem.)
>
> It is in the partition code. I posted twice before about this with no
> response.
It's not an important problem, presumably. I observe dual revalidations
as well, but they are not that bothersome. Add to it that your patch
appears wrong (see below). If you offered an acceptable solution, I would
expect a warmer welcome... But even then getting a reply from linux-scsi
folks is like pulling a tooth (if my own little CD-ROM sizing patch is
any indication). So, steel yourself for challenges of this life, Patrick!
> The changelog said it was a workaround for a borken device, but not what
> device it was or any other details.
Here's what it was in 2.6.9, as documented in drivers/block/ub.c:
+ /*
+* This is a workaround for a specific problem in our block layer.
+* In 2.6.9, register_disk duplicates the code from rescan_partitions.
+* However, if we do add_disk with a device which persistently reports
+* a changed media, add_disk calls register_disk, which does do_open,
+* which will call rescan_paritions for changed media. After that,
+* register_disk attempts to do it all again and causes double kobject
+* registration and a eventually an oops on module removal.
+*
+* The bottom line is, Al Viro says that we should not allow
+* bdev->bd_invalidated to be set when doing add_disk no matter what.
+*/
+ if (sc->first_open) {
+ if (sc->changed) {
+ sc->first_open = 0;
+ rc = -ENOMEDIUM;
+ goto err_open;
+ }
+ }
Users were hitting it with oopses like these:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0011.html
The ub alone was not suffient to motivate Al for the fix, so I added
this silly "first_open" thingie, which papered over it. It was thought
that sd was miraclously immune.
However, over time users hit it with usb-storage and sd, like this:
http://lkml.org/lkml/2004/2/21/19
This prompted Al's action. He simply dropped all the extra code like
this:
--- linux-2.6.9-11.5.EL/fs/partitions/check.c 2004-10-18 14:55:07.0
-0700
+++ linux-2.6.12/fs/partitions/check.c 2005-06-17 12:48:29.0 -0700
@@ -358,24 +357,9 @@ void register_disk(struct gendisk *disk)
if (!bdev)
return;
+ bdev->bd_invalidated = 1;
if (blkdev_get(bdev, FMODE_READ, 0) < 0)
return;
- state = check_partition(disk, bdev);
- if (state) {
- for (j = 1; j < state->limit; j++) {
- sector_t size = state->parts[j].size;
- sector_t from = state->parts[j].from;
- if (!size)
- continue;
- add_partition(disk, j, from, size);
-#ifdef CONFIG_BLK_DEV_MD
- if (!state->parts[j].flags)
- continue;
- md_autodetect_dev(bdev->bd_dev+j);
-#endif
- }
- kfree(state);
- }
blkdev_put(bdev);
}
I was just about to remove "first_open" from ub, because it's unnecessary
with Al's fix and it was getting on my nerves.
> --- linux-2.6.11-rc1/fs/partitions/check.cFri Dec 24 13:35:28 2004
> +++ no-double-sd-linux-2.6.11-rc1/fs/partitions/check.c Fri Jan 21
> 11:19:00 2005
> @@ -375,8 +375,6 @@ int rescan_partitions(struct gendisk *di
> bdev->bd_invalidated = 0;
> for (p = 1; p < disk->minors; p++)
> delete_partition(disk, p);
> - if (disk->fops->revalidate_disk)
> - disk->fops->revalidate_disk(disk);
As for your proposed fix, it may be problematic. The ->revalidate
method has to be called at least once for a new device, because
that's when drivers fetch the capacities. But ->open only calls
check_disk_change() for removable devices. Who is going to call
->revalidate inside add_disk() for non-removable devices?
-- Pete
-
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: HDAPS, Need to park the head for real
On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote: > On Tue, 2005-08-16 at 22:07 +0200, Jens Axboe wrote: > > On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote: > > If I were in your position, I would just implement this for ide (pata, > > not sata) right now, since that is what you need to support (or do some > > of these notebooks come with sata?). So it follows that you add an ide > > Some notebooks are coming up with a Sata controller I think, but is > still and IDE drive. I think some T43's come with that. > > But, I will ask or check again later if we ever need this feature for > SATA. Doing it for sata as well is just a little more work. The generic code is the same, but you probably need to add a per-queue hook for filling the request with the proper command setup. For ide that would be a REQ_DRIVE_TASKFILE, for libata you need to look at the pass through stuff. Everything else still applies. You're welcome, -- Jens Axboe - 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: compiling only one module in kernel version 2.6?
On Tue, 2005-08-16 at 22:41 -0700, Randy.Dunlap wrote: > > Sam only added make .ko build support very recently, > so it could easily depend on what kernel verison Fong is using. That could very well explain it. I'm doing this on 2.6.13-rc6-rt6 (2.6.13-rc6 with Ingo's rt6 patch applied). So I really do have a recent kernel. -- 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/
Re: 2.6.13-rc6-rt6
On Wed, 2005-08-17 at 00:20 -0400, Steven Rostedt wrote: > Ingo, > > FYI, I ran this on my laptop (Pentium4 HT) and it locked up shortly > after it started INIT. I rebooted, and now it's up and running > with no problems!?! I'll reboot it a few more times to see if it will > lock up again. With a small change it locks up all the time :-) > > Unfortunately, my laptop doesn't have any serial so I don't have much to > debug with it. I'll set up netconsole, but this is not as reliable > under RT, or was this fixed. I remember before that it could call things > that would schedule and had some hooks to keep interrupts on. > > Oh, I also did get the message when it started: > > WARNING: kstopmachine/859 changed soft IRQ-flags. > [] stop_machine+0x11b/0x160 (8) > [] do_stop+0xe/0x70 (32) > [] kthread+0xba/0xc0 (16) > [] kthread+0x0/0xc0 (28) > [] kernel_thread_helper+0x5/0x10 (16) I replaced this with raw_local_irq_disable and it really locks up everytime now. I need to look into how this is best done. > The kernel I used was rt6 with my latest patch to the > raw_local_save_flags. I just got the NMI working, but since it is now 1:44am my time, I'm going to bed. I'll run it again tomorrow and hopefully the NMI will show where and why it's locking up. -- 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/
Re: [PATCH] ppc32: removed usage of
On Aug 16, 2005, at 10:33 PM, David S. Miller wrote: From: Paul Mackerras <[EMAIL PROTECTED]> Date: Wed, 17 Aug 2005 11:38:20 +1000 Kumar Gala writes: Made a dummy include like it is in ppc64 and removed any users if it in arch/ppc. Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h too, for that matter) entirely? I concur, in fact we should really kill that thing off entirely. I'm all for killing it off entirely but got some feedback that on i386 segment.h can be included by userspace programs. Here is the in kernel consumers that are outside of arch specific directories: ./drivers/char/mxser.c:#include ./drivers/isdn/hisax/hisax.h:#include ./drivers/media/video/adv7170.c:#include ./drivers/media/video/adv7175.c:#include ./drivers/media/video/bt819.c:#include ./drivers/media/video/bt856.c:#include ./drivers/media/video/saa7111.c:#include ./drivers/media/video/saa7114.c:#include ./drivers/media/video/saa7185.c:#include ./drivers/serial/68328serial.c:#include ./drivers/serial/crisv10.c:#include ./drivers/serial/icom.c:#include ./drivers/serial/mcfserial.c:#include ./drivers/video/q40fb.c:#include ./include/linux/isdn.h:#include ./sound/oss/os.h:#include - kumar - 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][PATCH] Mobil Pentium 4 HT and the NMI
I'm trying to get the nmi working with my laptop (IBM ThinkPad G41) and
after debugging it a while, I found that the nmi code doesn't want to
set it up for this particular CPU.
Here I have:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz
stepping: 1
cpu MHz : 3320.084
cache size : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 1
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
monitor ds_cpl est tm2 cid xtpr
bogomips: 6642.39
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz
stepping: 1
cpu MHz : 3320.084
cache size : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 1
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
monitor ds_cpl est tm2 cid xtpr
bogomips: 6637.46
And the following code shows:
$ cat linux-2.6.13-rc6/arch/i386/kernel/nmi.c
[...]
void setup_apic_nmi_watchdog (void)
{
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_AMD:
if (boot_cpu_data.x86 != 6 && boot_cpu_data.x86 != 15)
return;
setup_k7_watchdog();
break;
case X86_VENDOR_INTEL:
switch (boot_cpu_data.x86) {
case 6:
if (boot_cpu_data.x86_model > 0xd)
return;
setup_p6_watchdog();
break;
case 15:
if (boot_cpu_data.x86_model > 0x3)
return;
Here I get boot_cpu_data.x86_model == 0x4. So I decided to change it
and reboot. I now seem to have a working NMI. So, unless there's
something know to be bad about this processor and the NMI. I'm
submitting the following patch.
-- Steve
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6-git1/arch/i386/kernel/nmi.c.orig 2005-08-17
01:34:21.0 -0400
+++ linux-2.6.13-rc6-git1/arch/i386/kernel/nmi.c2005-08-17
01:40:13.0 -0400
@@ -195,7 +195,7 @@ static void disable_lapic_nmi_watchdog(v
wrmsr(MSR_P6_EVNTSEL0, 0, 0);
break;
case 15:
- if (boot_cpu_data.x86_model > 0x3)
+ if (boot_cpu_data.x86_model > 0x4)
break;
wrmsr(MSR_P4_IQ_CCCR0, 0, 0);
@@ -432,7 +432,7 @@ void setup_apic_nmi_watchdog (void)
setup_p6_watchdog();
break;
case 15:
- if (boot_cpu_data.x86_model > 0x3)
+ if (boot_cpu_data.x86_model > 0x4)
return;
if (!setup_p4_watchdog())
-
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: compiling only one module in kernel version 2.6?
On Tue, 16 Aug 2005 23:18:49 -0400 Steven Rostedt wrote: > On Tue, 2005-08-16 at 19:09 -0700, Fong Vang wrote: > > What's the easiest way to compile just one module in the Linux 2.6 kernel > > tree? > > > > This no longer seem to work: > > > > $ cd /usr/src/linux > > $ make SUBDIRS=fs/reiserfs modules > >Building modules, stage 2. > >MODPOST > > > > I don't see any .ko generated. > > It worked for me. Is your reiserfs turned on as a module, and not > compiled into the kernel. ( not <*> nor < >) Sam only added make .ko build support very recently, so it could easily depend on what kernel verison Fong is using. --- ~Randy - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 06:47:45PM -0500, [EMAIL PROTECTED] wrote: > > From: Greg KH [mailto:[EMAIL PROTECTED] > > > And just to re-iterate one more time, we can already directly hook > > > into > > > hardware from userspace without any kernel auditing. We are > > just trying > > > to set this out on the table for everybody to see. > > > > So, this whole driver is not needed at all? It can all be > > done from userspace? If so, then this shouldn't be added to > > the kernel tree. > > Several reasons: > > A) Auditability: we don't do "secret" SMI calls behind people's backs. > This is an issue for some of our larger customers. This also provides a > legitimate reason that I can use to justify to management publicly > documenting the rest of the SMI calls that are not in use by our > software. Things like: "Hey, SomeBigDellCustomer wants to know what Dell > is doing with the open source dcdbas driver and all of the other SMI > function docs" pull a lot of weight. > > B) Safety: It is easier to provide a single API with well defined > semantics so there are no race conditions when multiple programs try to > do SMI at the same time. SMI from userspace can be tricky, and I want to > make it easy to get right. Things like finding an usused BIOS reserved > area and coordinating access between multiple programs can be difficult. > Additionally, finding an area large enough to hold everything for the > larger SMI calls is tricky (ie. depends on which system, BIOS memory > layout, etc. Very difficult to safely code for and mostly not worth the > effort if we can get this driver in). > > C) host control actions need to happen in kernel at shutdown, so that > part of the driver needs to be in the kernel. (this part isn't the part > that provides generic SMI stuff to userspace) Indeed, at least a little bit of kernel help is necessary for allocating coherent physical memory blocks below 4GB for SMI use, and is the best place to synchronize multiple users of those memory blocks. It need not offer much in the kernel, but it need offer at least that much. How much more appears to be the subject of the debate now. First, let me thank everyone for their time reviewing the code and providing food for thought. I value your input greatly. I've been looking at the suggesions about putting more of the functionality currently handled in userspace by libsmbios into the kernel. It's definitely possible, but I don't like it. In order of operations: 1) SMBIOS/DMI table parsing for OEM-specific data blocks. The present arch/i386/kernel/dmi_scan.c saves the normally useful information, but not OEM-specific data blocks, and the scanning and storing functions are all __init. It could be extended to save more data (mostly unused though), or to obtain it again at runtime if needed (remove __init), on behalf of the driver. libsmbios does this already without kernel driver help thanks to /dev/mem. 2) Token Discovery. Many of the tokens don't exist on any given system. For the ones mapped in CMOS, the SMBIOS tables tell you which ones exist. For those mapped by SMIs, there's no structure that tells you it exists - you must try it and find out. This would involve an awful lot of SMI calls at driver init time, to do discovery and not export files for nonexistent functions, when in practice most of the calls won't ever be used. You could skip the discovery and export all the functions as files, many of which would be useless on any given platform, and have those return -ENOTSUP. I'd prefer to have a userspace tool show the list of potential calls, and return akin to -ENOTSUP when any given call is tried but isn't available on that system. libsmbios does this already. 3) Reading/writing the values behind the CMOS/SMI tokens (BIOS F2 screen for example) requires that the tokens be exported first, ideally via sysfs. In SMBIOS tables, the tokens are identified by a number, not by a human-readable string, which is what you'd want when naming the entries in sysfs. The values for each token also aren't kept in human-readable strings, but in scalar values. To be useful, you'd need a mapping of token number to name, and token value to value name. You'd need to know the input validation routine for each token. And you'd need to extend this list any time a new token is added to any BIOS. One *could* use the request_firmware() to load in a table of these mappings from userspace, such that the mapping could be easily extended from userspace over time without having to change the driver regularly. Alternately, one could follow the PCI new_ids or SCSI /proc/scsi/device_info method of adding new token mappings on the fly. libsmbios already provides a mechanism to do this in userspace, and it's extensible (edit and load a new config file at runtime) in a similar fashion. So it's not impossible, but it seems like
Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()
Akira, Thanks for your suggestions. On 8/17/05, Akira Tsukamoto <[EMAIL PROTECTED]> wrote: > Anyway, going back to copy_user topic, > big remaining issues are > 1)store/restore floating point register (80/64bytes) twice every time by > surrounding with kernel_fpu_begin()/kernel_fpu_end() is big penalty I don't know. If nobody uses MMX/XMM, then there is no need to save and restore. > 2)after pagefault not always come back to copy function and corrupts fp > register I'm trying to understand this mechanism but I don't understand very well. > 3)disabling long preemption > Please correct me if I am wrong. > > I tried to implement fpsave inside pagefault handler once and here is my junk; > http://www.suna-asobi.com/~akira-t/linux/k7-copy-user/K7-copy_47_with_fpusave_not_finished.patch > never had a time to finish it. Hiro, does it help you? Thanks. I'm reading your patch but could not understand very well. I'll ask you. Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miraclelinux.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/
powernow-k8 cpufreq driver problems (fails to load on MSI k8n neo2 w/3500+)
Hi, I have two machines with similar specs (same motherboard and bios version), and one works fine with the cpufreq driver while the other machine is giving me the following messages below. powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.40.4) cpufreq-core: trying to register driver powernow-k8 cpufreq-core: adding CPU 0 powernow-k8: register performance failed: bad ACPI data powernow-k8: BIOS error - no PSB or ACPI _PSS objects cpufreq-core: initialization failed cpufreq-core: no CPU initialized for driver powernow-k8 cpufreq-core: unregistering CPU 0 I have done roughly 8 hours of google searching and research, have tried various kernel options, tried updating to the latest kernel, tried reverting to an earlier bios, but nothing seems to work. At this point, I think there may be an issue with the kernel. However, it doesn't make sense that the bios and powernow would work with a bleeding edge dual core processor, but not work with an older processor model on the same motherboard. I've obviously run out of ideas. If anyone has any suggestions or ideas, (or even better, a patch) I would really appreciate it. Strangely enough, the machine that works with powernow has a leading edge athlon 4800+, while the one that is broken is running an Athlon 3500+. Anyway, here are the details. Machine 1: (works with powernow) OS: Fedora Core 4 64 bit version, kernel 2.6.12.3 AMD Athlon 4800+ 3GB of RAM MSI K8N Neo2 Platinum motherboard with bios version 1.9 Nvidia Geforce 6800 GT video card (AGP) 3 hard drives, 2 SATA, 1 ATA ATI Tv Wonder PCI 1 Plextor DVD burner Machine 2:(fails to load powernow driver) OS: Fedora Cord 4 32 bit version, kernel 2.6.12.4 AMD Athlon 3500+ (venice core, stepping 2) MSI K8N Neo2 Platinum motherboard with bios version 1.9 1 GB of RAM Trident PCI video card (it's a file/mail server) 4 SATA drives in a RAID 5 array (data drives) 2 ATA drives in a RAID 1 array (boot drive) 1 NEC DVD RW (model 3504?) Here is the dmesg for machine 1: Bootdata ok (command line is ro root=LABEL=/1 rhgb quiet) Linux version 2.6.12.3 ([EMAIL PROTECTED]) (gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)) #2 SMP Thu Jul 21 03:48:06 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - bfff (usable) BIOS-e820: bfff - bfff3000 (ACPI NVS) BIOS-e820: bfff3000 - c000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) ACPI: RSDP (v000 Nvidia) @ 0x000f8f30 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0xbfff3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0xbfff30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0xbfff7b80 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0xbfff7ac0 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x On node 0 totalpages: 786416 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 782320 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 Nvidia board detected. Ignoring ACPI timer override. ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:3 APIC version 16 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:3 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at c000 (gap: c000:3ec0) Checking aperture... CPU 0: aperture @ e000 size 256 MB Built 1 zonelists Kernel command line: ro root=LABEL=/1 rhgb quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 3.579545 MHz PM timer. time.c: Detected 2411.790 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Memory: 3088432k/3145664k available (2361k kernel code, 56304k reserved, 1585k data, 220k init) Calibrating delay loop... 4784.12 BogoMIPS (lpj=2392064) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in
Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()
From: Hiro Yoshioka <[EMAIL PROTECTED]> Subject: Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll() Date: Wed, 17 Aug 2005 08:21:53 +0900 (JST) Message-ID: <[EMAIL PROTECTED]> > Chuck, > > From: Chuck Ebbert <[EMAIL PROTECTED]> > > On Tue, 16 Aug 2005 at 19:16:17 +0900 (JST), Hiro Yoshioka wrote: > > > oh, really? Does the linux kernel take care of > > > SSE save/restore on a task switch? > > > > Check out XMMS_SAVE and XMMS_RESTORE in include/asm-i386/xor.h > > Thanks for your suggestion. But it seems to me it won't help > when we have a page fault or other exeptions. Hi, Let me understand what the kernel does save/resfore FPU/MMX/XMM registers. Please let me know if I'm wrong. 1) kernel_fpu_begin() preempt_disable() if TS_USEDFPU then __save_init_fpu() ... save to tsk->thread.i387.f*save clear TS_USEDFPU flag of tsk->thread_info->status else clts() --- clear TS flag of CR0 2) copy MMX/XMM registers are used. 3) page faults/exceptions/... 3-1 TS flag is set by the CPU (Am I right?) if nobody uses MMX/XMM 3-2 it's fine. we don't need save/restore else 3-3 MMX/XMM is used When TS flag is set, the CPU monitors the instruction stream of X87 FPU/MMX/SSE/SSE2 instructions. When the CPU detects one of these instruction, it raises a device-not-available exception (#NM) prior to executing the instruction. (IA32 Software Developer's Manual, Vol. 3, 12.5.1) math_state_restore() is the device-not-available exception clts() if (!tsk_used_math(tsk)) init_fpu(tsk); restore_fpu(tsk); set TS_USEDFPU; 4) kernel_fpu_end() stts(); set TS flag of CR0 preempt_enable(); It seems to me that the kernel automatically save/restore FPU/MMX/XMM registers. What's wrong with it? Do I misunderstand it? Regards, Hiro - 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-latest] SCSI disk registration msgs repeat themselves
On Tue, Aug 16, 2005 at 11:01:30PM -0400, Chuck Ebbert wrote: > I just added some usb-storage devices to my system and got the below. > Why do the first four lines repeat for each device? (Not sure if > this is a SCSI or USB problem.) It is in the partition code. I posted twice before about this with no response. The changelog said it was a workaround for a borken device, but not what device it was or any other details. There is a patch (against 2.6.11) in the below, I haven't tried it with recent kernels: http://marc.theaimsgroup.com/?l=linux-scsi=110719123625593=2 http://marc.theaimsgroup.com/?l=linux-scsi=110848617107098=2 -- Patrick Mansfield - 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-rt6
Ingo, FYI, I ran this on my laptop (Pentium4 HT) and it locked up shortly after it started INIT. I rebooted, and now it's up and running with no problems!?! I'll reboot it a few more times to see if it will lock up again. Unfortunately, my laptop doesn't have any serial so I don't have much to debug with it. I'll set up netconsole, but this is not as reliable under RT, or was this fixed. I remember before that it could call things that would schedule and had some hooks to keep interrupts on. Oh, I also did get the message when it started: WARNING: kstopmachine/859 changed soft IRQ-flags. [] stop_machine+0x11b/0x160 (8) [] do_stop+0xe/0x70 (32) [] kthread+0xba/0xc0 (16) [] kthread+0x0/0xc0 (28) [] kernel_thread_helper+0x5/0x10 (16) --- | preempt count: ] | 0-level deep critical section nesting: -- | showing all locks held by: | (kstopmachine/859 [f74dc840, 0]): -- The kernel I used was rt6 with my latest patch to the raw_local_save_flags. Config attached. -- Steve config-bilbo.bz2 Description: application/bzip
Re: [PATCH] [Fwd: Console locking and blanking]
On Tue, 2005-08-16 at 21:55 -0600, Alejandro Bonilla Beeche wrote: > On Tue, 2005-08-16 at 23:44 -0400, Steven Rostedt wrote: > > On Wed, 2005-08-17 at 13:29 +1000, Benjamin Herrenschmidt wrote: > > > On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: > > > > > > > (I'm blind and I use a braille display. I use those functions to blank > > > > my laptop's screen so people don't read it, and hopefully to conserve > > > > power.) > > > > At the OLS I learned that the backlight of a laptop (when the screen is > > black, but still glows) actually spends more wattage than when the > > screen is lit. So, unless you actually turn the laptop display off, > > switching it to black will actually burn the battery quicker. > > This sounds stupid. Who told you this? The actual brightness is the one > that consumes the most battery. > > Seriously, who told you such thing? > It was one of the speakers during the presentation. He seemed to know what he was talking about, in fact, I was caught so off guard by the statement, I got up and ask him the question again. "Did you say that the backlight of the laptop takes up more energy than when it is on?" and he replied "yes"! I rememeber this being in room C (could be wrong, I went to so many sessions). Looking at the program, it could have been "Linux Power Management" by Patrick Mochel. But I honestly don't remember which session it was. (I'm CCing him to see if he can clear things up :-) -- 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/
Re: [PATCH] [Fwd: Console locking and blanking]
On Tue, 2005-08-16 at 23:44 -0400, Steven Rostedt wrote: > On Wed, 2005-08-17 at 13:29 +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: > > > > > (I'm blind and I use a braille display. I use those functions to blank > > > my laptop's screen so people don't read it, and hopefully to conserve > > > power.) > > At the OLS I learned that the backlight of a laptop (when the screen is > black, but still glows) actually spends more wattage than when the > screen is lit. So, unless you actually turn the laptop display off, > switching it to black will actually burn the battery quicker. This sounds stupid. Who told you this? The actual brightness is the one that consumes the most battery. Seriously, who told you such thing? .Alejandro - 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] [Fwd: Console locking and blanking]
On Tue, 2005-08-16 at 23:44 -0400, Steven Rostedt wrote: > On Wed, 2005-08-17 at 13:29 +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: > > > > > (I'm blind and I use a braille display. I use those functions to blank > > > my laptop's screen so people don't read it, and hopefully to conserve > > > power.) > > At the OLS I learned that the backlight of a laptop (when the screen is > black, but still glows) actually spends more wattage than when the > screen is lit. So, unless you actually turn the laptop display off, > switching it to black will actually burn the battery quicker. Actually, it's not the backlight. The backlight definitely eats less power when off. The panel itself, however, at least some of them afaik, will use a bit more power for opaque pixels than for transparent pixels. Ben. - 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] [Fwd: Console locking and blanking]
As an alternative to using VT IOCTLs you should be able to echo these values to /sys/class/graphics/fb0/blank and blank the screen. The attribute is pretty new so it hasn't had a lot of testing on the various fbdev drivers. #define VESA_NO_BLANKING0 #define VESA_VSYNC_SUSPEND 1 #define VESA_HSYNC_SUSPEND 2 #define VESA_POWERDOWN 3 On 8/16/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: > > > (I'm blind and I use a braille display. I use those functions to blank > > my laptop's screen so people don't read it, and hopefully to conserve > > power.) > > Oops ! I _am_not_ the one who is blind, though thanks a lot for some of > the comments ;) I just forgot the line: > > From: Stéphane Doyon <[EMAIL PROTECTED]> > > (I'm still stuck to Signed-off-by only lines) > > > Stephane is to congratulate for this fix. > > Ben. > > > - > 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/ > -- Jon Smirl [EMAIL PROTECTED] - 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: net-irda-possible-cleanups.patch added to -mm tree
I've put this into the net-2.6.14 tree. - 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] [Fwd: Console locking and blanking]
On Wed, 2005-08-17 at 13:29 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: > > > (I'm blind and I use a braille display. I use those functions to blank > > my laptop's screen so people don't read it, and hopefully to conserve > > power.) At the OLS I learned that the backlight of a laptop (when the screen is black, but still glows) actually spends more wattage than when the screen is lit. So, unless you actually turn the laptop display off, switching it to black will actually burn the battery quicker. -- 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/
Re: [PATCH] ppc32: removed usage of
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Wed, 17 Aug 2005 11:38:20 +1000 > Kumar Gala writes: > > > Made a dummy include like it is in ppc64 and removed any > > users if it in arch/ppc. > > Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h > too, for that matter) entirely? I concur, in fact we should really kill that thing off entirely. - 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] [Fwd: Console locking and blanking]
On Wed, 2005-08-17 at 11:41 +1000, Benjamin Herrenschmidt wrote: > (I'm blind and I use a braille display. I use those functions to blank > my laptop's screen so people don't read it, and hopefully to conserve > power.) Oops ! I _am_not_ the one who is blind, though thanks a lot for some of the comments ;) I just forgot the line: From: Stéphane Doyon <[EMAIL PROTECTED]> (I'm still stuck to Signed-off-by only lines) Stephane is to congratulate for this fix. Ben. - 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: [ANNOUNCE] iproute2 util update
Stephen Hemminger a écrit :
http://developer.osdl.org/dev/iproute2/download/iproute2-050816.tar.gz
Update to iproute2 to include:
* Limit ip neigh flush to 10 rounds
* tc ematch support (thomas)
* build cleanups (thomas, et al)
* Fix for options process with ipt (jamal)
* Fix array overflow in paretonormal distribution build
* Update include files to 2.6.13
* Decnet doc update (Steven Whithouse)
Note: the ematch support won't build on really old versions of bison (1.28),
but the kernel on those systems wouldn't support it anyway.
-
Thank you
Could you please apply this patch.
* Fix lnstat : First column should not be summed
Thank you
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- iproute2-050816-orig/misc/lnstat_util.c 2005-03-18 20:40:19.0
+0100
+++ iproute2-050816/misc/lnstat_util.c 2005-08-17 05:21:04.0 +0200
@@ -55,7 +55,7 @@
for (j = 0; j < lf->num_fields; j++) {
unsigned long f = strtoul(ptr, , 16);
if (j == 0)
- lf->fields[j].values[i] += f;
+ lf->fields[j].values[i] = f;
else
lf->fields[j].values[i] += f;
}
Re: compiling only one module in kernel version 2.6?
On Tue, 2005-08-16 at 19:09 -0700, Fong Vang wrote: > What's the easiest way to compile just one module in the Linux 2.6 kernel > tree? > > This no longer seem to work: > > $ cd /usr/src/linux > $ make SUBDIRS=fs/reiserfs modules >Building modules, stage 2. >MODPOST > > I don't see any .ko generated. It worked for me. Is your reiserfs turned on as a module, and not compiled into the kernel. ( not <*> nor < >) -- 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/
[2.6.13-rc6-latest] SCSI disk registration msgs repeat themselves
I just added some usb-storage devices to my system and got the below. Why do the first four lines repeat for each device? (Not sure if this is a SCSI or USB problem.) [ 23.433725] SCSI device sda: 63424 512-byte hdwr sectors (32 MB) [ 23.560564] sda: Write Protect is off [ 23.560581] sda: Mode Sense: 02 00 00 00 [ 23.560593] sda: assuming drive cache: write through [ 23.572525] SCSI device sda: 63424 512-byte hdwr sectors (32 MB) [ 23.576504] sda: Write Protect is off [ 23.576519] sda: Mode Sense: 02 00 00 00 [ 23.576530] sda: assuming drive cache: write through [ 23.576545] sda: sda1 [ 23.583752] Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 [ 23.583847] Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0 [ 23.584701] usb-storage: device scan complete [ 32.116248] SCSI device sdb: 196608 512-byte hdwr sectors (101 MB) [ 32.141310] sdb: Write Protect is off [ 32.153477] sdb: Mode Sense: 45 00 00 08 [ 32.153490] sdb: assuming drive cache: write through [ 32.178386] SCSI device sdb: 196608 512-byte hdwr sectors (101 MB) [ 32.204473] sdb: Write Protect is off [ 32.216654] sdb: Mode Sense: 45 00 00 08 [ 32.216735] sdb: assuming drive cache: write through [ 32.233259] sdb: sdb4 [ 32.246595] Attached scsi removable disk sdb at scsi2, channel 0, id 0, lun 0 [ 32.270348] Attached scsi generic sg2 at scsi2, channel 0, id 0, lun 0, type 0 [ 32.295843] usb-storage: device scan complete __ Chuck - 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 for 2.6.13] iSeries build with newer assemblers and compilers
From: Stephen Rothwell <[EMAIL PROTECTED]>
Paulus suggested that we put xLparMap in its own .c file so that we can
generate a .s file to be included into head.S. This doesn't get around
the problem of having it at a fixed address, but it makes it more
palatable.
It would be good if this could be included in 2.6.13 as it solves our
build problems with various versions of binutils and gcc. In
particular, it allows us to build an iSeries kernel on Debian unstable
using their biarch compiler.
This has been built and booted on iSeries and built for pSeries and g5.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
arch/ppc64/kernel/LparData.c| 79
arch/ppc64/kernel/Makefile |5 ++
arch/ppc64/kernel/head.S|6 ++
arch/ppc64/kernel/lparmap.c | 31 ++
include/asm-ppc64/iSeries/LparMap.h |9 +++-
5 files changed, 51 insertions(+), 79 deletions(-)
diff -ruN linus/arch/ppc64/kernel/LparData.c
linus-lparmap.2/arch/ppc64/kernel/LparData.c
--- linus/arch/ppc64/kernel/LparData.c 2005-07-28 11:23:11.0 +1000
+++ linus-lparmap.2/arch/ppc64/kernel/LparData.c2005-08-16
17:13:16.0 +1000
@@ -32,32 +32,12 @@
/* The HvReleaseData is the root of the information shared between
* the hypervisor and Linux.
*/
-
-/*
- * WARNING - magic here
- *
- * Ok, this is a horrid hack below, but marginally better than the
- * alternatives. What we really want is just to initialize
- * hvReleaseData in C as in the #if 0 section here. However, gcc
- * refuses to believe that (u32) is a constant expression, so will
- * not allow the xMsNucDataOffset field to be properly initialized.
- * So, we declare hvReleaseData in inline asm instead. We use inline
- * asm, rather than a .S file, because the assembler won't generate
- * the necessary relocation for the LparMap either, unless that symbol
- * is declared in the same source file. Finally, we put the asm in a
- * dummy, attribute-used function, instead of at file scope, because
- * file scope asms don't allow contraints. We want to use the "i"
- * constraints to put sizeof() and offsetof() expressions in there,
- * because including asm/offsets.h in C code then stringifying causes
- * all manner of warnings.
- */
-#if 0
struct HvReleaseData hvReleaseData = {
.xDesc = 0xc8a5d9c4,/* "HvRD" ebcdic */
.xSize = sizeof(struct HvReleaseData),
.xVpdAreasPtrOffset = offsetof(struct naca_struct, xItVpdAreas),
.xSlicNacaAddr = , /* 64-bit Naca address */
- .xMsNucDataOffset = (u32)((unsigned long) - KERNELBASE),
+ .xMsNucDataOffset = LPARMAP_PHYS,
.xFlags = HVREL_TAGSINACTIVE/* tags inactive */
/* 64 bit */
/* shared processors */
@@ -70,63 +50,6 @@
0xa7, 0x40, 0xf2, 0x4b,
0xf4, 0x4b, 0xf6, 0xf4 },
};
-#endif
-
-
-extern struct HvReleaseData hvReleaseData;
-
-static void __attribute_used__ hvReleaseData_wrapper(void)
-{
- /* This doesn't appear to need any alignment (even 4 byte) */
- asm volatile (
- " lparMapPhys = xLparMap - %3\n"
- " .data\n"
- " .globl hvReleaseData\n"
- "hvReleaseData:\n"
- " .long 0xc8a5d9c4\n" /* xDesc */
- /* "HvRD" in ebcdic */
- " .short %0\n" /* xSize */
- " .short %1\n" /* xVpdAreasPtrOffset */
- " .llong naca\n" /* xSlicNacaAddr */
- " .long lparMapPhys\n" /* xMsNucDataOffset */
- " .long 0\n"/* xRsvd1 */
- " .short %2\n" /* xFlags */
- " .short 4\n"/* xVrmIndex - v5r2m0 */
- " .short 3\n"/* xMinSupportedPlicVrmIndex - v5r1m0 */
- " .short 3\n"/* xMinCompatablePlicVrmIndex - v5r1m0
*/
- " .long 0xd38995a4\n" /* xVrmName */
- " .long 0xa740f24b\n" /* "Linux 2.4.64" ebcdic */
- " .long 0xf44bf6f4\n"
- " . = hvReleaseData + %0\n"
- " .previous\n"
- : : "i"(sizeof(hvReleaseData)),
- "i"(offsetof(struct naca_struct, xItVpdAreas)),
- "i"(HVREL_TAGSINACTIVE /* tags inactive, 64 bit, */
- /* shared processors, HMT allowed */
- | 6), /* TEMP: This allows non-GA drivers */
- "i"(KERNELBASE)
- );
-}
-
-struct LparMap __attribute__((aligned (16))) xLparMap = {
- .xNumberEsids = HvEsidsToMap,
- .xNumberRanges = HvRangesToMap,
-
Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11
> > > Interrupts are disabled during usb_hcd_giveback_urb because that's how > > > it was done originally and nobody has made an effort to remove this > > > assumption from the USB device drivers. Also Host Controller Drivers (HCDs). You do sort of have to remember who's calling this routine. It's normally an HCD in the middle of its IRQ processing, tending hardware. I'd actually say the reason that has IRQs disabled is because of the amount of work that would have been involved in changing that assumption ... I actually did look at what it'd take to let IRQs be enabled during USB completion callbacks a while back, and concluded it'd be a lot of work for hardly any return. > > > There's no real reason for it > > > other than historical inertia. It's not done for serialization -- > > > there's no need for serialization since an URB can't be resubmitted > > > before the previous callback occurs (unless a driver is badly broken). > > > The "detached" method is used simply to avoid an extra pair of > > > enable/disable instructions. > > > > so we can remove it altogether, via the patch below? Sounds dangerous to me. > > (If there's any > > unsafe driver, it should already be unsafe on SMP, and with the > > proliferation of HT and dual-core CPUs, SMP will be the norm within a > > year or so - so the sooner we trigger any breakages, the better i > > guess.) > > > > i'll give it a whirl in the -RT tree. > > In general yes, the patch should be okay. But there are a few things to > check for. Perhaps most of the USB drivers don't care whether interrupts > are enabled or not in their completion routines. And in general, all drivers have been _allowed_ to know that IRQs are disabled in completion handlers ever since the earliest 2.2 kernels that included USB support. Changes like that -- interactions between at least three obvious subsystems (usbcore, usb drivers, hcds) and lots of unobvious ones (whoever the drivers talk to) -- sound rather error prone to me. Worth taking very cautiously, with lots of regression testing of stress loads on some of the funkier hardware. Not that I'm deeply opposed to such changes, you understand, but there seem to be three choices here: 1 ALWAYS complete() with IRQs disabled 2 NEVER complete() with them disabled 3 SOMETIMEs complete() with them disabled. Right now we're with #1 which is simple, consistent and guaranteed. We couldn't switch to #2 with patches that simple. They'd in fact be rather involved, because there is logic like "If the endpoint's queue is empty when the completion handler returns, then deschedule that queueue" inside IRQ handlers. Basic things, like correctness, for periodic scheduling depend on such logic. And I don't see much point to #3. It's got all the DIS-advantages of #1 and #2 and the advantages of neither ... - 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.4 and 2.6 kernel module
Found the answer by googling further. It's been renamed to vermagic. strings reiserfs.ko|grep vermagic vermagic=2.6.9-11.EL 586 REGPARM 4KSTACKS gcc-3.4 On 8/16/05, Fong Vang <[EMAIL PROTECTED]> wrote: > In the 2.4 kernel, modules contain the "kernel_version" identification > in the module itself. This is an example from the 2.4.18 reiserfs > kernel module: > > kernel_version=2.4.18-27.7.xbigmem > using_checksums=1 > description=ReiserFS journaled filesystem > author=Hans Reiser <[EMAIL PROTECTED]> > license=GPL > kernel_version=2.4.18-27.7.xbigmem > using_checksums=1 > > > This ID doesn't seem to exist anymore in the 2.6 kernel. How does a > 2.6 kernel know if a module is compatible? > > Thanks for any help. > - 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/
compiling only one module in kernel version 2.6?
What's the easiest way to compile just one module in the Linux 2.6 kernel tree? This no longer seem to work: $ cd /usr/src/linux $ make SUBDIRS=fs/reiserfs modules Building modules, stage 2. MODPOST I don't see any .ko generated. - 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] API for timer hooks
On Wed, 2005-08-17 at 00:21 +0400, Stas Sergeev wrote: > 1. It needs the higher interrupt frequency. > Since there seem to be no API to change > the timer frequency at runtime, the driver > does this itself. Now I have googled out > the thread Wow, your driver implements bass and treble controls by varying the frequency of the timer interrupt. That's a neat hack, but I'd expect it to raise a few eyebrows if it's submitted for mainline... 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.4 and 2.6 kernel module
In the 2.4 kernel, modules contain the "kernel_version" identification in the module itself. This is an example from the 2.4.18 reiserfs kernel module: kernel_version=2.4.18-27.7.xbigmem using_checksums=1 description=ReiserFS journaled filesystem author=Hans Reiser <[EMAIL PROTECTED]> license=GPL kernel_version=2.4.18-27.7.xbigmem using_checksums=1 This ID doesn't seem to exist anymore in the 2.6 kernel. How does a 2.6 kernel know if a module is compatible? Thanks for any help. - 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: rcu read-side protection
On Tue, Aug 16, 2005 at 05:09:29PM -0700, Suzanne Wood wrote: [ . . . ] > A read-side critical section is marked to protect the dereference of the > dn_ptr and assignment to dn_db which is a pointer to a dn_dev. (struct > net_device is defined in /linux/netdevice.h and its dn_ptr in > /include/net/dn_dev.h) Should this rcu-protection be extended to the line > following rcu_read_lock()? Even though use_long is a simple char, it > appears to be a member of an rcu-protected structure. Looks to me that this could indeed be a problem -- the structure pointed to by dn_db could potentially be freed immediately after the rcu_read_unlock(), unless there is some other non-obvious locking mechanism protecting it. In which case, why the rcu_read_lock() and rcu_read_unlock()... Thanx, Paul - 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: PowerOP 0/3: System power operating point management API
Dominik Brodowski wrote: A small add-on: We need to make sure that we're capable of handling smart CPUs like Transmeta Crusoe processors in a sane way. This means b) Setting of "values" is optional if the hardware itself can be set to a min/max value (step a above in previous mail). Although I haven't looked into the Crusoe processor support, it may be that there is a different set of power parameters, not cpu speed directly, that are appropriate to manage on these platforms (after a brief look, seems to be a range of frequencies and some sort of flags)? If so, these sorts of machine-specific power parameters are what PowerOP is trying to address, allowing management of the underlying machine-specific stuff to upper layers that may be presenting an abstracted view of power/performance, such as CPU speed or speed ranges, to the user. Thanks, -- Todd - 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] Use RCU to protect tasklist for unicast signals
On Tue, Aug 16, 2005 at 10:07:14AM -0700, Paul E. McKenney wrote:
> On Tue, Aug 16, 2005 at 03:56:05PM +0400, Oleg Nesterov wrote:
> > Paul E. McKenney wrote:
> > >
> > > OK, the attached instead revalidates that the task struct still references
> > > the sighand_struct after obtaining the lock
> >
> > Personally I think this is a way to go. A nitpick suggestion,
> > could you make a separate function (say, lock_task_sighand)
> > which does all this job?
>
> Sounds good, will do!
>
> The other thing that jumped out at me is that signals are very different
> animals from a locking viewpoint depending on whether they are:
>
> 1.ignored,
>
> 2.caught by a single thread,
>
> 3.fatal to multiple threads/processes (though I don't know
> of anything that shares sighand_struct between separate
> processes), or
>
> 4.otherwise global to multiple threads/processes (such as
> SIGSTOP and SIGCONT).
>
> And there are probably other distinctions that I have not yet caught
> on to.
>
> One way to approach this would be to make your suggested lock_task_sighand()
> look at the signal and acquire the appropriate locks. If, having acquired
> a given set of locks, it found that the needed set had changed (e.g., due
> to racing exec() or sigaction()), then it drops the locks and retries.
>
> Does this make sense?
>
> This approach assumes that realtime latency (of the kill() operation
> itself) is critical only cases #1 and #2 above. This makes sense to me,
> but some of you might know of situations where #3 and #4 are important.
> But I am hoping not. ;-)
OK, for this sort of approach to work, lock_task_sighand() must take and
return some sort of mask indicating what locks are held. The mask returned
by lock_task_sighand() would then be passed to an unlock_task_sighand().
Another alternative would be to make a macro that allowed an arbitrary
statement to be wrapped up in it.
Neither of these are as appealing as I would like -- other ideas?
I have not yet attacked this in the attached patch.
> > > > and there are some remaining problems
> > > > that I need to sort out, including:
> > > ...
> > >
> > > o Some of the functions invoked by __group_send_sig_info(),
> > > including handle_stop_signal(), momentarily drop ->siglock.
> >
> > Just to be sure that one point doesn't escape your attention, this:
> >
> > > +++
> > > linux-2.6.13-rc4-realtime-preempt-V0.7.53-01-tasklistRCU/kernel/signal.c
> > > 2005-08-14 19:53:28.0 -0700
> > > @@ -328,9 +328,11 @@ void __exit_sighand(struct task_struct *
> > > struct sighand_struct * sighand = tsk->sighand;
> > >
> > > /* Ok, we're done with the signal handlers */
> > > + spin_lock(>siglock);
> > > tsk->sighand = NULL;
> > > if (atomic_dec_and_test(>count))
> > > - kmem_cache_free(sighand_cachep, sighand);
> > > + sighand_free(sighand);
> > > + spin_unlock(>siglock);
> >
> > is not enough (and unneeded). Unless I missed something, we have
> > a race:
> >
> > release_task:
> >
> > __exit_signal:
> > spin_lock(sighand);
> > spin_unlock(sighand);
> > flush_sigqueue(>shared_pending);
> > kmem_cache_free(tsk->signal);
> > // here comes
> > group_send_sig_info(), locks ->sighand,
> > // delivers the signal
> > to the ->shared_pending.
> > // siginfo leaked, or
> > crash.
> > __exit_sighand:
> > spin_lock(sighand);
> > tsk->sighand = NULL;
> > // too late
> >
> > I think that release_task() should not use __exit_sighand()
> > at all. Instead, __exit_signal() should set tsk->sighand = NULL
> > under ->sighand->lock.
>
> Will look into this -- I was inserting the locking to handle a race with
> my revalidation. It looks like I also need to pay some more attention
> to the race with exiting tasks, good catch! Your suggestion of invoking
> __exit_signal() from under siglock within __exit_signal() sounds good
> at first glance, will think it through.
This turned out to be easy, the attached patch covers it.
> > > int group_send_sig_info(int sig, struct siginfo *info, struct
> > > task_struct *p)
> > > {
> > > unsigned long flags;
> > > + struct sighand_struct *sp;
> > > int ret;
> > >
> > > +retry:
> > > ret = check_kill_permission(sig, info, p);
> > > - if (!ret && sig && p->sighand) {
> > > + if (!ret && sig && (sp = p->sighand)) {
> > > if (!get_task_struct_rcu(p)) {
> > > return -ESRCH;
> > > }
> > > - spin_lock_irqsave(>sighand->siglock, flags);
> > > + spin_lock_irqsave(>siglock, flags);
> > > + if (p->sighand != sp) {
> > > + spin_unlock_irqrestore(>siglock, flags);
> > > + put_task_struct(p);
> > > + goto retry;
> > > +
[PATCH] [Fwd: Console locking and blanking]
I've had WARN_CONSOLE_UNLOCKED warnings when calling TIOCLINUX TIOCL_BLANKSCREEN and TIOCL_UNBLANKSCREEN. (I'm blind and I use a braille display. I use those functions to blank my laptop's screen so people don't read it, and hopefully to conserve power.) The warnings are from these places: do_blank_screen at drivers/char/vt.c:2754 (Not tainted) save_screen at drivers/char/vt.c:575 (Not tainted) do_unblank_screen at drivers/char/vt.c:2822 (Not tainted) set_palette at drivers/char/vt.c:2908 (Not tainted) At a glance I would think the following patch ought to fix that. Tested on one machine. Could you please tell me if this is correct and/or forward the patch where appropriate... Signed-off-by: Stéphane Doyon <[EMAIL PROTECTED]> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- linux-2.6.12/drivers/char/vt.c.orig 2005-08-16 15:39:14.0 -0400 +++ linux-2.6.12/drivers/char/vt.c 2005-08-16 15:41:04.0 -0400 @@ -2272,7 +2272,9 @@ ret = paste_selection(tty); break; case TIOCL_UNBLANKSCREEN: + acquire_console_sem(); unblank_screen(); + release_console_sem(); break; case TIOCL_SELLOADLUT: ret = sel_loadlut(p); @@ -2317,8 +2319,10 @@ } break; case TIOCL_BLANKSCREEN: /* until explicitly unblanked, not only poked */ + acquire_console_sem(); ignore_poke = 1; do_blank_screen(0); + release_console_sem(); break; case TIOCL_BLANKEDSCREEN: ret = console_blanked; - 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: PowerOP 0/3: System power operating point management API
Dominik Brodowski wrote: First, the table interface you suggest is ugly. If there's indeed the need for such an abstraction, I'd favour something like I'm planning to adopt the previous suggestions of an opaque data structure and stop trying to have any generic structure to it. I'll try to leave dependency checking etc. to the upper layers as much as possible, since platforms vary greatly in this and so do the needs of different PM s/w stacks. Secondly, you do not adress the cross-relationships between operation points correctly. If you change the CPU frequency, you may have to switch other (memory, video) settings; you might even have to validate the frequency settings for these or even additional reasons (thermal and battery reasons - ACPI _PPC). This lowest layer basically assumes that upper-layer software has created an appropriate operating point (for example, in DPM we pretty much require a system designer to create operating points that match the h/w specs and don't go to great lengths to encode rules about this), and/or will call driver notifiers etc. as needed to adapt to the changes. Although there may be some sanity checking appropriate at the PowerOP level, cpufreq, DPM, etc. can for the most part continue to handle the larger issues of how valid operating points are constructed, driver callbacks, etc. If you do want to handle various dependencies at the PowerOP layer then there's nothing that prevents that, but PM frameworks tend to embody assumptions about how frequently operating points will change and in what contexts (interrupt, idle...), and this can influence the code for such things. Thirdly, who is to decide on the power management settings? The first and intuitive answer is the kernel. Therefore, kernel-space cpufreq governors exist. Only under rare circumstances, you want full userspace control -- that's what the userspace cpufreq governor is for. Also something left to the existing upper layers; PowerOP isn't intended to handle any of that. In the embedded space we usually let the system designer choose operating points supported by their h/w vendor and that match their particular system states (hardware enabled at any point in time, type and power/performance needs of software currently running). We do recommend that a userspace power policy manager be the component in charge of PM settings, based on messages from drivers and other apps on the state of the system. And so that userspace component activates the operating point (or set of operating points in the case of DPM) appropriate for current state. Foruthly, the code duplication which your implementation leads to is obvious for the speedstep-centrino case. We could move the tables of valid cpu speeds and corresponding voltages down to the PowerOP level, and there would probably be little duplication at that point (in fact, with the current patch there's not a lot of duplication since the actual MSR access was moved to PowerOP and PowerOP contains little else, but both levels know how to understand the MSR format, and a more aggressive port to PowerOP could do away with that). Your suggestions of changes to cpufreq governors and policies to handle governance of non-cpu-speed parameters sound interesting, and I'd be happy to help figure out what to do about those vs. the lower machine access layer I've discussed up until now. I'll think more about this real soon now. Thanks, -- Todd - 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] ppc32: removed usage of
Kumar Gala writes: > Made a dummy include like it is in ppc64 and removed any > users if it in arch/ppc. Why can't we just delete asm-ppc/segment.h (and asm-ppc64/segment.h too, for that matter) entirely? Paul. - 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 - 0/9] Generic timekeeping subsystem (v. B5)
On Wed, 2005-08-17 at 02:28 +0200, Roman Zippel wrote: > Let's look at the example patch below. I played a little with some code > and this just demonstrates an accurate conversion of the tick/freq values > into the internal values in ns resolution. It does a little more work > ahead, but the interrupt code becomes simpler and most important it > doesn't require any expensive 64bit math and you can't get it much more > accurate than that. The current gettimeofday code for tick based sources > is really cheap and I'd like to keep that (i.e. free of 64bit math). The > accuracy can and should be fixed (the change to timespec wasn't really a > major improvement, as it introduced new rounding errors). Hmm. It could really use some comments, but it looks interesting. Let me continue reading it and play around with it some more. > The other thing the example demonstrates is the interface from NTP to > timer code. The NTP code provides the basic parameters and then leaves it > to the clock implementation how they apply. The adjustment and phase > variables are really private variables. If they are private clock variables, why are they in the generic timer.c? Everyone is using it in exactly the same way, no? Why do you oppose having the adjustment and phase values behind an ntp_function() interface? Maybe to focus this productively, I'll try to step back and outline the goals at a high level and you can address those. My Assumptions: 1. adjtimex() sets/gets NTP state values 2. Every tick we adjust those state values 3. Every tick we use those values to make a nanosecond adjustment to time. 4. Those state values are otherwise unused. Goals: 1. Isolate NTP code to clean up the tick based timekeeping, reducing the spaghetti-like code interactions. 2. Add interfaces to allow for continuous, rather then tick based, adjustments (much how ppc64 does currently, only shareable). thanks -john - 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/
routes disappear
I've been having an intermittent problem over the last couple of years where the addition of a network interface will cause all routes on the box to vanish. the systems are a stripped down Debian 3.0 build with a 2.6.7 kernel and the vast majority of the time they work just fine. however once in a while I get a config where enabling an interface causes netstat (and /proc/net/route) to report no routes. The system continues to function so the routes are still there somehow, but they aren't reported. the latest box to do this has two interfaces (this one has tg3 interfaces, but I've also seen this on adaptec starfire, tulip, and 3com nics) 192.168.242.142 192.168.210.219 if I boot the box with the interfaces disabled and do ifup individually it sometimes works (I haven't nailed down the difference between when it does and when it doesn't), if I leave them enabled at boot by the time I can login the routing table shows blank. I have a few days to fiddle with this system before I need to use it, where should I look to dig up more info? syslog shows the following Aug 16 16:33:04 scribe1a-p kernel: Adding 2048276k swap on /dev/sda1. Priority:-1 extents:1 Aug 16 16:33:04 scribe1a-p kernel: ttyS2: LSR safety check engaged! Aug 16 16:33:04 scribe1a-p kernel: ttyS2: LSR safety check engaged! Aug 16 16:33:04 scribe1a-p kernel: ttyS3: LSR safety check engaged! Aug 16 16:33:04 scribe1a-p kernel: ttyS3: LSR safety check engaged! Aug 16 16:33:04 scribe1a-p kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex. Aug 16 16:33:04 scribe1a-p kernel: tg3: eth0: Flow control is on for TX and on for RX. Aug 16 16:33:04 scribe1a-p kernel: tg3: eth1: Link is up at 1000 Mbps, full duplex. Aug 16 16:33:04 scribe1a-p kernel: tg3: eth1: Flow control is off for TX and off for RX. Aug 16 16:33:04 scribe1a-p kernel: process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT Aug 16 16:33:05 scribe1a-p /usr/sbin/gpm[191]: Detected EXPS/2 protocol mouse. Aug 16 16:33:07 scribe1a-p ntpd[298]: ntpd 4.1.0 Mon Mar 25 23:39:47 UTC 2002 (2) Aug 16 16:33:07 scribe1a-p ntpd[298]: precision = 11 usec Aug 16 16:33:07 scribe1a-p ntpd[298]: kernel time discipline status 0040 Aug 16 16:33:07 scribe1a-p ntpd[298]: attempt to configure invalid address 127.127.1.0 Aug 16 16:33:07 scribe1a-p /usr/sbin/cron[303]: (CRON) INFO (pidfile fd = 3) Aug 16 16:33:07 scribe1a-p /usr/sbin/cron[304]: (CRON) STARTUP (fork ok) Aug 16 16:33:07 scribe1a-p /usr/sbin/cron[304]: (CRON) INFO (Running @reboot jobs) Aug 16 16:33:16 scribe1a-p ntpd[298]: sendto(192.168.252.132): Network is unreachable Aug 16 16:33:23 scribe1a-p ntpd[298]: sendto(192.168.252.131): Network is unreachable Aug 16 16:33:36 scribe1a-p kernel: 192.168.242.142 sent an invalid ICMP type 3, code 1 error to a broadcast: 192.168. 242.255 on lo Aug 16 16:33:36 scribe1a-p kernel: 192.168.242.142 sent an invalid ICMP type 3, code 1 error to a broadcast: 192.168. 242.255 on lo Aug 16 16:33:39 scribe1a-p kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex. Aug 16 16:33:39 scribe1a-p kernel: tg3: eth0: Flow control is on for TX and on for RX. Aug 16 16:33:42 scribe1a-p kernel: 192.168.210.216 sent an invalid ICMP type 3, code 1 error to a broadcast: 192.168. 210.255 on lo Aug 16 16:33:42 scribe1a-p kernel: 192.168.210.216 sent an invalid ICMP type 3, code 1 error to a broadcast: 192.168. 210.255 on lo Aug 16 16:33:43 scribe1a-p kernel: tg3: eth1: Link is up at 1000 Mbps, full duplex. Aug 16 16:33:43 scribe1a-p kernel: tg3: eth1: Flow control is off for TX and off for RX. Aug 16 16:33:55 scribe1a-p kernel: tg3: eth1: Link is up at 1000 Mbps, full duplex. Aug 16 16:33:55 scribe1a-p kernel: tg3: eth1: Flow control is off for TX and off for RX. Aug 16 16:34:01 scribe1a-p /USR/SBIN/CRON[716]: (root) CMD (touch /tmp/.crond_running >/dev/null 2>/dev/null) Aug 16 16:34:02 scribe1a-p kernel: 192.168.242.142 sent an invalid ICMP type 3, code 1 error to a broadcast: 192.168. 242.255 on lo Aug 16 16:34:02 scribe1a-p kernel: 192.168.242.142 sent an invalid ICMP type 3, code 1 error to a broadcast: 192.168. 242.255 on lo Aug 16 16:34:04 scribe1a-p kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex. Aug 16 16:34:04 scribe1a-p kernel: tg3: eth0: Flow control is on for TX and on for RX. Aug 16 16:35:01 scribe1a-p /USR/SBIN/CRON[1126]: (root) CMD (/usr/local/etc/newlogs >/dev/null 2>/dev/null) Aug 16 16:35:01 scribe1a-p /USR/SBIN/CRON[1128]: (root) CMD (touch /tmp/.crond_running >/dev/null 2>/dev/null) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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
[patch] KGDB for Real-Time Preemption systems
I have put a version of KGDB for x86 RT kernels here: http://source.mvista.com/~ganzinger/ The common_kgdb_cfi_ stuff creates debug records for entry.S and friends so that you can "bt" through them. Apply in this order: Ingo's patch kgdb-ga-rt.patch common_kgdb_cfi_annotations.patch This is, more or less, the same kgdb that is in Andrew's mm tree changed to fix the RT issues. -- 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: [RFC][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Wed, 2005-08-17 at 02:23 +0200, Andi Kleen wrote: > <[EMAIL PROTECTED]> writes: > > 2) Dell OpenManage > > The main use of this driver by openmanage will be to read the System > > Event Log that BIOS keeps. Here are some other random relevant points: > > Are there machine check events from the last boot in that event log? I don't know. Either Doug or Abhay may, though. If they don't I can ask the BIOS guys. -- Michael - 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: [UPDATE PATCH] push rounding up of relative request to schedule_timeout()
Nishanth Aravamudan wrote: On 04.08.2005 [09:45:55 -0700], George Anzinger wrote: Uh... PLEASE tell me you are NOT changing timespec_to_jiffies() (and timeval_to_jiffies() to add 1. This is NOT the right thing to do. For repeating times (see setitimer code) we need the actual time as we KNOW where the jiffies edge is in the repeating case. The +1 is needed ONLY for the initial time, not the repeating time. See: http://marc.theaimsgroup.com/?l=linux-kernel=112208357906156=2 I followed that thread, George, but I think it's a different case with schedule_timeout() [maybe this indicates drivers/other users should maybe be using itimers, but I'll get to that in a sec]. I think I miss understood back then :). With schedule_timeout(), we are just given a relative jiffies value. We have no context as to which task is requesting the delay, per se, meaning we don't (can't) know from the interface whether this is the first delay in a sequence, or a brand new one, without changing all users to have some sort of control structure. The callers of schedule_timeout() don't even get a pointer to the timer added internally. So, adding 1 to all sleeps seems like it might be reasonable, as looping sleeps probably need to use a different interface. I had worked a bit ago on something like poll_event() with the kernel-janitors group, which would abstract out the repeated sleeps. Basically wait_event() without wait-queues... Maybe we could make such an interface just use itimers? I've attached my old patch for poll_event(), just for reference. I think not. itimers is really pointed at a particular system call and has resources in the task structure to do it. These would be hard to share... My point, I guess, is that in the schedule_timeout() case, we don't know where the jiffies edge is, as we either expire or receive a wait-queue event/signal, we never mod_timer() the internal timer... So we have to assume that we need to sleep the request. But maybe Roman's idea of sleeping a certain number of jiffy edges is sufficient. I am not yet convinced driver authors want/need such an interface, though, still thinking it over. IMNSHO we should not get too parental with kernel only interfaces. Adding 1 is easy enough for the caller and even easier to explain in the instructions (i.e. this call sleeps for X jiffies edges). This allows the caller to do more if needed and, should he ever just want to sync to the next jiffie he does not have to deal with backing out that +1. -- 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: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
Hi,
On Mon, 15 Aug 2005, john stultz wrote:
> > Please provide the right abstractions, e.g. leave the gettimeofday
> > implementation to the timesource and use some helper (template) functions
> > to do the actual work. Basically as long as you have a cycle_t in the
> > common code something is really wrong, this code belongs in the continous
> > clock template.
>
> I'm not sure I agree. By pushing all the gettimeofday logic behind the
> timesource or clock class you describe above, you end up with lots of
> duplicated and error prone code.
That's there template code comes in, so that the drivers need only to add
little code themselves. The point is that every time source has different
requirements and if we want efficient implementations, too much common
code doesn't really help. It's a tradeoff.
Let's look at the example patch below. I played a little with some code
and this just demonstrates an accurate conversion of the tick/freq values
into the internal values in ns resolution. It does a little more work
ahead, but the interrupt code becomes simpler and most important it
doesn't require any expensive 64bit math and you can't get it much more
accurate than that. The current gettimeofday code for tick based sources
is really cheap and I'd like to keep that (i.e. free of 64bit math). The
accuracy can and should be fixed (the change to timespec wasn't really a
major improvement, as it introduced new rounding errors).
The other thing the example demonstrates is the interface from NTP to
timer code. The NTP code provides the basic parameters and then leaves it
to the clock implementation how they apply. The adjustment and phase
variables are really private variables. In the code below it's rather
easily possible to make HZ another parameter and you can have clocks
running at different frequencies (e.g. to implement dynamic ticks). A low
frequency timer provides the wall clock and a separate timer takes care of
the kernel timer.
The code below needs of course a little more work, currently I use it to
collect some data on how the current code behaves. I'll add the adjustment
code and then I'll see how it compares to it.
> > This also allows better implementations, e.g. gettimeofday can be done in
> > a single step instead of two using a single lock instead of two.
>
> This is a miss-characterization. In most cases the continuous
> gettimeofday is done in a single step with a single lock. Although it
> does have the flexibility to allow for more complex setups, as well as
> the ability to opt out and use the existing tick based code.
You have it the wrong way around. In the general case you need two locks
and only in some cases can you optimize one away. To evaluate the
complexity of the design you really have to look at the general case for
each component. You're rather focused on just the best cases.
bye, Roman
---
kernel/time.c |3 ++-
kernel/timer.c | 53 +
2 files changed, 55 insertions(+), 1 deletion(-)
Index: linux-2.6/kernel/time.c
===
--- linux-2.6.orig/kernel/time.c2005-07-13 03:18:04.0 +0200
+++ linux-2.6/kernel/time.c 2005-08-16 01:37:20.0 +0200
@@ -366,8 +366,9 @@ int do_adjtimex(struct timex *txc)
} /* txc->modes & ADJ_OFFSET */
if (txc->modes & ADJ_TICK) {
tick_usec = txc->tick;
- tick_nsec = TICK_USEC_TO_NSEC(tick_usec);
}
+ if (txc->modes & (ADJ_FREQUENCY|ADJ_OFFSET|ADJ_TICK))
+ time_recalc();
} /* txc->modes */
leave: if ((time_status & (STA_UNSYNC|STA_CLOCKERR)) != 0
|| ((time_status & (STA_PPSFREQ|STA_PPSTIME)) != 0
Index: linux-2.6/kernel/timer.c
===
--- linux-2.6.orig/kernel/timer.c 2005-07-13 03:18:04.0 +0200
+++ linux-2.6/kernel/timer.c2005-08-16 23:10:53.0 +0200
@@ -559,6 +559,7 @@ found:
*/
unsigned long tick_usec = TICK_USEC; /* USER_HZ period (usec) */
unsigned long tick_nsec = TICK_NSEC; /* ACTHZ period (nsec) */
+unsigned long tick_nsec2 = TICK_NSEC;
/*
* The current time
@@ -569,6 +570,7 @@ unsigned long tick_nsec = TICK_NSEC;/*
* the usual normalization.
*/
struct timespec xtime __attribute__ ((aligned (16)));
+struct timespec xtime2 __attribute__ ((aligned (16)));
struct timespec wall_to_monotonic __attribute__ ((aligned (16)));
EXPORT_SYMBOL(xtime);
@@ -596,6 +598,33 @@ static long time_adj; /* tick adjust (
long time_reftime; /* time at last adjustment (s) */
long time_adjust;
long time_next_adjust;
+static long time_adj2, time_adj2_cur, time_freq_adj2, time_freq_phase2,
time_phase2;
+
+void time_recalc(void)
+{
+ long f, t;
+ tick_nsec = TICK_USEC_TO_NSEC(tick_usec);
+
Re: [patch 3/7] PCI: fix quirk-6700-fix.patch
Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote:
>
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> drivers/built-in.o(.text+0x32c3): In function `quirk_pcie_pxh':
> /usr/src/25/drivers/pci/quirks.c:1312: undefined reference to
> `disable_msi_mode'
>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
> ---
> drivers/pci/pci.h |6 ++
> 1 files changed, 6 insertions(+)
>
> --- gregkh-2.6.orig/drivers/pci/pci.h 2005-08-16 14:57:46.0 -0700
> +++ gregkh-2.6/drivers/pci/pci.h 2005-08-16 14:57:47.0 -0700
> @@ -46,7 +46,13 @@ extern int pci_msi_quirk;
> #else
> #define pci_msi_quirk 0
> #endif
> +
> +#ifdef CONFIG_PCI_MSI
> void disable_msi_mode(struct pci_dev *dev, int pos, int type);
> +#else
> +static inline void disable_msi_mode(struct pci_dev *dev, int pos, int type)
> { }
> +#endif
> +
> extern int pcie_mch_quirk;
> extern struct device_attribute pci_dev_attrs[];
> extern struct class_device_attribute class_device_attr_cpuaffinity;
>
hm. I normally fold crappy little patches like this into the main patch
before sending it Linuswards. The submitter gets a mention in the s-o-b
record and perhaps a one-line description if the fix was less than utterly
trivial.
That's one advantage of the patch-scripts/quilt approach: these little
post-facto fixups don't pollute the upstream changelog record.
-
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 8/14] i386 / Add a per cpu gdt accessor
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Tue, Aug 16, 2005 at 05:07:36PM -0700, Chris Wright wrote: > > * Andi Kleen ([EMAIL PROTECTED]) wrote: > > > On Wed, Aug 10, 2005 at 09:56:40PM -0700, [EMAIL PROTECTED] wrote: > > > > Add an accessor function for getting the per-CPU gdt. Callee must > > > > already > > > > have the CPU. > > > > > > What is the accessor good for? > > > > > > It looks just like code obfuscation to me. > > > > Xen handles gdt differently (one page per cpu instead of per_cpu data). > > So this is for handling that access cleanly. > > It would be much cleaner to use a per_cpu pointer then and just allocate > it differently. OK, that's easily done, but it will add extra indirection. This currently changes nothing for common case. The cpu_gdt_descr effectively has that address cached already (just not as per_cpu). - 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/14] i386 / Make write ldt return error code
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Tue, Aug 16, 2005 at 05:06:18PM -0700, Chris Wright wrote: > > In this case the callers do propagate the error (unless you mean > > userspace doesn't check return value from syscall, which is same problem > > if copy_from_user failed, for example). Xen has done some more wrapping > > Nothing checks them in user space. > > Also how would you handle them anyways? It just doesn't make sense. Yes, I see your point, although copy_from_user failing has similar issue if userspace isn't checking errors. But this one is not critical. thanks, -chris - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
<[EMAIL PROTECTED]> writes: > 2) Dell OpenManage > The main use of this driver by openmanage will be to read the System > Event Log that BIOS keeps. Here are some other random relevant points: Are there machine check events from the last boot in that event log? If yes it would be extremly cool to feed this data into mcelog using the /dev/mcelog device after boot up. It probably would need a few functions in exported in arch/x86_64/kernel/mce.c, but I would be fine with that. The advantage would be that all machine checks would be in a common log and can be easily analyzed by higher level infrastructure (like a cluster manager) The code used to dump the MCEs from the hardware registers left over at boot, but so many BIOS keep bogus data in there that this had to be turned off. Only tricky part might be to make sure this data is not logged twice. I think it would be better to do this in kernel space if it's simple enough. In theory mcelog could get a write method too so that user space could inject events, but that would have the disadvantage that everybody distribution would need a magic Dell specific program to just do that. In the kernel it would just work transparently. /dev/mcelog only exists on x86-64 right now, but will probably appear on i386 at some point too. -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: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Tue, 16 Aug 2005, john stultz wrote: > That is why I'm suggesting time_interpolator users to move to my code > (when they're ready, of course :). Both are basically timesources. That is why I would suggest you upgrade the interpolators to timesources. Doing that would enable a gradual transition instead of a cutover to a new time subsystem. It should also insure that the gains we have made in terms of accuracy of time will be preserved in the new system. And the code would be able to use the existing proven code that already allows system time with nanosecond precision. - 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 8/14] i386 / Add a per cpu gdt accessor
On Tue, Aug 16, 2005 at 05:07:36PM -0700, Chris Wright wrote: > * Andi Kleen ([EMAIL PROTECTED]) wrote: > > On Wed, Aug 10, 2005 at 09:56:40PM -0700, [EMAIL PROTECTED] wrote: > > > Add an accessor function for getting the per-CPU gdt. Callee must already > > > have the CPU. > > > > What is the accessor good for? > > > > It looks just like code obfuscation to me. > > Xen handles gdt differently (one page per cpu instead of per_cpu data). > So this is for handling that access cleanly. It would be much cleaner to use a per_cpu pointer then and just allocate it differently. -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: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
On Tue, 2005-08-16 at 17:14 -0700, Christoph Lameter wrote: > On Tue, 16 Aug 2005, john stultz wrote: > > > This is basically what I do in my patch. I directly apply the NTP > > adjustment to the timesource interval, and periodically increment the > > NTP state machine by the timesource interval when we accumulate it. > > Is there some way to tell the NTP code how much the time_interpolator time > deviates from xtime? > > If the NTP code would use getnstimeofday or > do_gettimeofday then it would already get interpolated time. That seems a bit backwards, no? > The curious issue in the current arrangement is that the interpolator > knows much more accurately how much time has passed between interrupts > than the timer interrupt but it has no time to make that information > available to the NTP code. That is why I'm suggesting time_interpolator users to move to my code (when they're ready, of course :). thanks -john - 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 - 0/9] Generic timekeeping subsystem (v. B5)
On Tue, 16 Aug 2005, john stultz wrote: > This is basically what I do in my patch. I directly apply the NTP > adjustment to the timesource interval, and periodically increment the > NTP state machine by the timesource interval when we accumulate it. Is there some way to tell the NTP code how much the time_interpolator time deviates from xtime? If the NTP code would use getnstimeofday or do_gettimeofday then it would already get interpolated time. The curious issue in the current arrangement is that the interpolator knows much more accurately how much time has passed between interrupts than the timer interrupt but it has no time to make that information available to the NTP code. - 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/14] i386 / Make write ldt return error code
On Tue, Aug 16, 2005 at 05:06:18PM -0700, Chris Wright wrote: > * Andi Kleen ([EMAIL PROTECTED]) wrote: > > On Wed, Aug 10, 2005 at 09:52:51PM -0700, [EMAIL PROTECTED] wrote: > > > Xen requires error returns from the hypercall to update LDT entries, > > > and this generates completely equivalent code on native. > > > > I don't think that is something we want. Nothing in the callers will check > > the errors anyways. If Xen has such a requirement it should kill > > the guest when it is violated, otherwise they will be ignored. > > In this case the callers do propagate the error (unless you mean > userspace doesn't check return value from syscall, which is same problem > if copy_from_user failed, for example). Xen has done some more wrapping Nothing checks them in user space. Also how would you handle them anyways? It just doesn't make sense. -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: [RFC - 0/13] NTP cleanup work (v. B5)
Hi, On Mon, 15 Aug 2005, john stultz wrote: > > I think most of this is premature cleanup. As it also changes the logic in > > small ways, I'm not even sure it qualifies as a cleanup. > > Please, Roman, I'm spending quite a bit of time breaking this up into > small chunks specifically to help this discussion. Rather then just > stating that the logic is changed in small ways, could you please be > specific and point to where that logic has changed and we can fix or > discuss it. Well, part of the problem is that you didn't really explain, why your logical are better in any way. You broke them out of your big patch and they lose their context. It's probably better to first to understand and agree on the functional changes, moving code around can still be done afterwards. > > For the rest I can't agree on to move everything that aggressively into > > the ntp namespace. The kernel clock is controlled via NTP, but how it > > actually works has little to do with "network time". > > Eh? The adjtimex() interface causes a small adjustment to be added or > removed from the system time each tick. Why should this code not be put > behind a clear interface? I don't mind the clear interface... > > Some of the > > parameters are even private clock variables (e.g. time adjustment, phase), > > which don't belong in any common code. (I'll expand on that in the next > > mail.) > > Again, I'm not understanding your objection. Its exactly because the > time_adjust and phase values are NTP specific variables that I'm trying > to move them from the timer.c code into ntp.c The point is you're starting at the wrong point, first we need a clean clock interface, only then should we change the ntp code to it. (More again in the next mail.) bye, Roman - 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 5/14] i386 / Use early clobber to eliminate rotate in desc
Zachary Amsden wrote: This one in particular is non-optimal looking from C because the compiler misses the potential for rotation. But, composing into temporaries and then issuing two writes to memory instead of multiple writes within the same word could actually get you a better cycle count, and that is something GCC just might be able to do :) At least i386 and x86-64 gcc should recognize ((foo << x) + (foo >> (32-x))) ... as a 32-bit rotate; similar for 8-, 16- and 64-bit rotates of appropriate sized items. Also, it seems it could just be an inline function instead of a macro. -hpa - 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 8/14] i386 / Add a per cpu gdt accessor
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Wed, Aug 10, 2005 at 09:56:40PM -0700, [EMAIL PROTECTED] wrote: > > Add an accessor function for getting the per-CPU gdt. Callee must already > > have the CPU. > > What is the accessor good for? > > It looks just like code obfuscation to me. Xen handles gdt differently (one page per cpu instead of per_cpu data). So this is for handling that access cleanly. thanks, -chris - 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/14] i386 / Make write ldt return error code
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Wed, Aug 10, 2005 at 09:52:51PM -0700, [EMAIL PROTECTED] wrote: > > Xen requires error returns from the hypercall to update LDT entries, > > and this generates completely equivalent code on native. > > I don't think that is something we want. Nothing in the callers will check > the errors anyways. If Xen has such a requirement it should kill > the guest when it is violated, otherwise they will be ignored. In this case the callers do propagate the error (unless you mean userspace doesn't check return value from syscall, which is same problem if copy_from_user failed, for example). Xen has done some more wrapping of the hypercalls to be effectively synchronous exceptions on error. Keir, Ian, is that preferred method going forward? thanks, -chris - 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 5/14] i386 / Use early clobber to eliminate rotate in desc
Andi Kleen wrote: On Wed, Aug 10, 2005 at 09:54:11PM -0700, [EMAIL PROTECTED] wrote: Use an early clobber on addr to avoid the extra rorl instruction at the end of _set_tssldt_desc. I would suggest to just use C for this. I do this on x86-64 and I don't think there is any reason to use this hard to maintain code for it. This one in particular is non-optimal looking from C because the compiler misses the potential for rotation. But, composing into temporaries and then issuing two writes to memory instead of multiple writes within the same word could actually get you a better cycle count, and that is something GCC just might be able to do :) Zach - 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: rc6 keeps hanging and blanking displays
> ... > > Seems like it died trying to perform int10 initialization? I'm still pointing towards that assign pci resources patch from Gregs tree that I mentioned earlier.. the fact that disabling the DRM stops things from working is really bad, maybe the pci_enable_device in the DRM is setting up the devices, whereas without it X tries and fails... > > I can try running the radeon xserver only, as the vga console is on the matrox > card. > I'm running low on ideas, I'm also having a hard time tracking what is actually happening, the MGA bugs I've tracked are related to that assign pci resources patch, and I really can't see what is happening if the DRM isn't in the mix.. If you build a working kernel (i.e. like 2.6.13 without DRM) does it hang similarly? 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 4/14] i386 / Clean up asm and volatile keywords in desc
Andi Kleen wrote: On Wed, Aug 10, 2005 at 09:53:51PM -0700, [EMAIL PROTECTED] wrote: Stop using extra underscores on asm and volatiles, that is just silly. Actually the volatiles might be still useful. Or if you drop them at least add memory clobbers. I had sometimes bugs on x86-64 with the compiler moving such assembly statements with invisible side effects around too aggressively and causing weird problems. Agreed on the underscores, I hate them too :) Well, put volatiles in *unless* the only effect of an asm statement is producing the output values. -hpa - 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 4/14] i386 / Clean up asm and volatile keywords in desc
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Wed, Aug 10, 2005 at 09:53:51PM -0700, [EMAIL PROTECTED] wrote: > > Stop using extra underscores on asm and volatiles, that is just silly. > > Actually the volatiles might be still useful. Or if you drop them > at least add memory clobbers. They are still there, just the underscores on both asm and volatile got pulled. > I had sometimes bugs on x86-64 > with the compiler moving such assembly statements with invisible > side effects around too aggressively and causing weird problems. > > Agreed on the underscores, I hate them too :) Heh, same here ;-) thanks, -chris - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
> -Original Message- > From: Greg KH [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 16, 2005 6:24 PM > To: Brown, Michael E > Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > Warzecha, Douglas; Domsch, Matt > Subject: Re: [RFC][PATCH 2.6.13-rc6] add Dell Systems > Management Base Driver (dcdbas) with sysfs support > > > On Tue, Aug 16, 2005 at 06:11:13PM -0500, > [EMAIL PROTECTED] wrote: > > > > The main use of this driver by libsmbios will be to set BIOS F2 > > options. Based on your feedback, I will _NOT_ be implementing any > > fan/sensor functionality in libsmbios, but will work with > the lmsensors > > guys to do this instead. I only originally mentioned it because I > > thought it would be useful. My eyes have now been opened as > to the best > > way to do this, and we will do it that way. > > Ok, sounds good. > > Hm, what about my code comments, they seem to have been lost > in the noise... No, they are not lost. Doug is working on them and will send you something shortly (EOD today). > > > And just to re-iterate one more time, we can already directly hook > > into > > hardware from userspace without any kernel auditing. We are > just trying > > to set this out on the table for everybody to see. > > So, this whole driver is not needed at all? It can all be > done from userspace? If so, then this shouldn't be added to > the kernel tree. Several reasons: A) Auditability: we don't do "secret" SMI calls behind people's backs. This is an issue for some of our larger customers. This also provides a legitimate reason that I can use to justify to management publicly documenting the rest of the SMI calls that are not in use by our software. Things like: "Hey, SomeBigDellCustomer wants to know what Dell is doing with the open source dcdbas driver and all of the other SMI function docs" pull a lot of weight. B) Safety: It is easier to provide a single API with well defined semantics so there are no race conditions when multiple programs try to do SMI at the same time. SMI from userspace can be tricky, and I want to make it easy to get right. Things like finding an usused BIOS reserved area and coordinating access between multiple programs can be difficult. Additionally, finding an area large enough to hold everything for the larger SMI calls is tricky (ie. depends on which system, BIOS memory layout, etc. Very difficult to safely code for and mostly not worth the effort if we can get this driver in). C) host control actions need to happen in kernel at shutdown, so that part of the driver needs to be in the kernel. (this part isn't the part that provides generic SMI stuff to userspace) -- Michael - 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 8/14] i386 / Add a per cpu gdt accessor
Andi Kleen wrote: On Wed, Aug 10, 2005 at 09:56:40PM -0700, [EMAIL PROTECTED] wrote: Add an accessor function for getting the per-CPU gdt. Callee must already have the CPU. What is the accessor good for? It looks just like code obfuscation to me. He wants accessors so he can override them in Xen. -hpa - 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 - 0/9] Generic timekeeping subsystem (v. B5)
On Tue, 2005-08-16 at 11:25 -0700, Christoph Lameter wrote: > You mentioned that the NTP code has some issues with time interpolation > at the KS. This is due to the NTP layer not being aware of actual time > differences between timer interrupts that the interpolator knows about. My understanding of the issue was that when NTP makes an adjustment, it only affects xtime, and any difference between the adjusted time and the interpolator's time was just accumulated in the interpolator's offset. That then, to my understanding, required the bit about adjusting the interpolator frequency to be slower then what we expect so negative offsets can be applied. Looking at it closer, it may very work, but it does seem to be addressing the issue somewhat indirectly. > If the NTP layer would be aware of the actual intervals measured by the > timesource (or interpolator) then presumably time could be adjusted in a > more accurate way. This is basically what I do in my patch. I directly apply the NTP adjustment to the timesource interval, and periodically increment the NTP state machine by the timesource interval when we accumulate it. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix mmap_kmem (was: [question] What's the difference between /dev/kmem and /dev/mem)
On Wed, 2005-08-17 at 00:33 +0100, Alan Cox wrote: > > If you use /dev/mem you should know what you are doing. Even with > "checks" dd if=/dev/zero of=/dev/mem will do bad things. Trapping > obviously bad cases is fine, but complete sanity checking may actually > be counter productive. > Sometimes "dd if=/dev/zero of=/dev/mem" is helpful. When I was in Spain for some time, I needed to transfer lots of pictures to my home machine. But all I had access to was a broken Windows box that I could ssh but not scp? So I (stupidly) started a ftp daemon and started transfering them that way. I thought that creating a temp account and then changing the password via ssh would work. Well, the next day I was completely rooted (thank god it was only a box in my DMZ). Still, I was thousands of miles away and needed to kill the box. If I can't use it, I certainly wont let someone else use it. They took over pretty much all control to shutdown the machine remotely. So I finally was able to do the duty with "dd if=/dev/zero of=/dev/mem". And that's my story where that can be your friend :-) -- 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/
Re: [PATCH 8/14] i386 / Add a per cpu gdt accessor
On Wed, Aug 10, 2005 at 09:56:40PM -0700, [EMAIL PROTECTED] wrote: > Add an accessor function for getting the per-CPU gdt. Callee must already > have the CPU. What is the accessor good for? It looks just like code obfuscation to me. -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: [RFC][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Mon, Aug 15, 2005 at 10:52:48PM -0700, Greg KH wrote:
> On Mon, Aug 15, 2005 at 03:05:22PM -0500, Doug Warzecha wrote:
> > +
> > +1) Lock smi_data.
> > +2) Determine buffer size needed for system management command.
> > +3) Write buffer size needed to smi_data_buf_size.
> > + (Driver will ensure that its SMI data buffer is at least that size.)
>
> Why have this step? Why is it needed? Just go off of the size of the
> buffer that is written to smi_data. Or am I missing something?
I'll change smi_data_write to do that.
> > +4) If physical address of SMI data buffer is needed to set up system
> > + management command, read physical address from smi_data_buf_phys_addr
> > + and add to command data.
>
> How do you know this?
It depends on the SMI calling convention. Dell OpenManage needs the physical
address for the SMI to get the ESM log on the PowerEdge systems listed in this
doc.
> > +#define DCDBAS_DEV_ATTR_RW(_name) \
> > + DEVICE_ATTR(_name,0644,_name##_show,_name##_store);
> > +
> > +#define DCDBAS_DEV_ATTR_RO(_name) \
> > + DEVICE_ATTR(_name,0444,_name##_show,NULL);
>
> Why let all users read this data?
Will be changed so that only owner can read.
> > +#define DCDBAS_BIN_ATTR_RW(_name) \
> > +struct bin_attribute bin_attr_##_name = { \
> > + .attr = { .name = __stringify(_name), \
> > + .mode = 0644, \
>
> Why let everyone read this data?
Will be changed so that only owner can read.
> > +struct callintf_cmd {
> > + u32 magic;
>
> Why even have this? Does it really stop anything except random
> scribblings?
It's to stop random writing.
> > + u16 command_address;
> > + u8 command_code;
> > + u8 reserved;
> > + u32 command_signature;
> > + u8 command_buffer[1];
> > +} __attribute__ ((packed));
>
> As these cross the userspace/kernelspace boundry, please use the __u32,
> __u16, and __u8 variable types.
Will be changed.
> > +struct apm_cmd {
> > + u8 command;
> > + s8 status;
> > + u16 reserved;
> > + union {
> > + struct {
> > + u8 parm[MAX_SYSMGMT_SHORTCMD_PARMBUF_LEN];
> > + } __attribute__ ((packed)) shortreq;
> > +
> > + struct {
> > + u16 num_sg_entries;
> > + struct {
> > + u32 size;
> > + u64 addr;
> > + } __attribute__ ((packed))
> > + sglist[MAX_SYSMGMT_LONGCMD_SGENTRY_NUM];
> > + } __attribute__ ((packed)) longreq;
> > + } __attribute__ ((packed)) parameters;
> > +} __attribute__ ((packed));
>
> Same here (I think...)
Will be changed.
Doug
-
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 6/14] i386 / Add some segment convenience functions
On Wed, Aug 10, 2005 at 09:54:31PM -0700, [EMAIL PROTECTED] wrote: > Add some convenient segment macros to the kernel. This makes the > rather obfuscated 'seg & 4' go away. segment_from_ldt is a weird name for this. I wouldn't guess it to be a test for something. How about is_ldt_segment() instead? -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: [PATCH 5/14] i386 / Use early clobber to eliminate rotate in desc
On Wed, Aug 10, 2005 at 09:54:11PM -0700, [EMAIL PROTECTED] wrote: > Use an early clobber on addr to avoid the extra rorl instruction at the > end of _set_tssldt_desc. I would suggest to just use C for this. I do this on x86-64 and I don't think there is any reason to use this hard to maintain code for it. It's probably a left over from Linus first experiments with inline assembly, similar to the old string.h and by now so obsolete it doesn't even stink anymore. -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: [PATCH 1/14] i386 / Make write ldt return error code
On Wed, Aug 10, 2005 at 09:52:51PM -0700, [EMAIL PROTECTED] wrote: > Xen requires error returns from the hypercall to update LDT entries, > and this generates completely equivalent code on native. I don't think that is something we want. Nothing in the callers will check the errors anyways. If Xen has such a requirement it should kill the guest when it is violated, otherwise they will be ignored. I would drop that one. -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: [PATCH 4/14] i386 / Clean up asm and volatile keywords in desc
On Wed, Aug 10, 2005 at 09:53:51PM -0700, [EMAIL PROTECTED] wrote: > Stop using extra underscores on asm and volatiles, that is just silly. Actually the volatiles might be still useful. Or if you drop them at least add memory clobbers. I had sometimes bugs on x86-64 with the compiler moving such assembly statements with invisible side effects around too aggressively and causing weird problems. Agreed on the underscores, I hate them too :) -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: udev-067 and 2.6.12?
On Wednesday 17 August 2005 00:09, Kay Sievers wrote: [snip] > > Do you provide hooks for handling /etc/hotplug.d/? We are on the way of > getting rid of that directory and recent udev versions don't handle > that by default anymore. If you don't know, read the udev RELEASE-NOTES. > > Kay I read the document, fixed the rules, and it works again. I've sent additional emails to the correct list this time outlining some other problems. I suspect they, too, are hotplug related. (In future I'll read the documentation available in its entirety before pestering people. However, the way udev works is constantly changing and the problem I was seeing was seemingly inconsistent with an otherwise working udev, which made me think the problem was more deep seated..) -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: [Hdaps-devel] Re: HDAPS, Need to park the head for real
On 8/16/05, Alejandro Bonilla Beeche <[EMAIL PROTECTED]> wrote: > On Tue, 2005-08-16 at 22:07 +0200, Jens Axboe wrote: > > On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote: > > If I were in your position, I would just implement this for ide (pata, > > not sata) right now, since that is what you need to support (or do some > > of these notebooks come with sata?). So it follows that you add an ide > > Some notebooks are coming up with a Sata controller I think, but is > still and IDE drive. I think some T43's come with that. > > But, I will ask or check again later if we ever need this feature for > SATA. I believe T43s use a SATA->PATA bridge for their hard drives, so we probably would. (see http://www.thinkwiki.org/wiki/Category_talk:T43). Yani - 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] cache pollution aware __copy_from_user_ll()
Chuck, From: Chuck Ebbert <[EMAIL PROTECTED]> > On Tue, 16 Aug 2005 at 19:16:17 +0900 (JST), Hiro Yoshioka wrote: > > oh, really? Does the linux kernel take care of > > SSE save/restore on a task switch? > > Check out XMMS_SAVE and XMMS_RESTORE in include/asm-i386/xor.h Thanks for your suggestion. But it seems to me it won't help when we have a page fault or other exeptions. Regards, Hiro - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
On Tue, Aug 16, 2005 at 06:11:13PM -0500, [EMAIL PROTECTED] wrote: > > The main use of this driver by libsmbios will be to set BIOS F2 > options. Based on your feedback, I will _NOT_ be implementing any > fan/sensor functionality in libsmbios, but will work with the lmsensors > guys to do this instead. I only originally mentioned it because I > thought it would be useful. My eyes have now been opened as to the best > way to do this, and we will do it that way. Ok, sounds good. Hm, what about my code comments, they seem to have been lost in the noise... > And just to re-iterate one more time, we can already directly hook into > hardware from userspace without any kernel auditing. We are just trying > to set this out on the table for everybody to see. So, this whole driver is not needed at all? It can all be done from userspace? If so, then this shouldn't be added to the kernel tree. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.3 clock drifting twice too fast (amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Lameter wrote: > On Tue, 16 Aug 2005, jerome lacoste wrote: > >>Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme >>AX 300 SE/t mainboard. >> >>I remember seeing a message in the boot saying something along: >> >> "cannot connect to hardware clock." >> >>And now I see that the time is changing too fast (about 2 seconds each >>second). > > The timer interrupt is probably called twice for some reason and therefore > time runs twice as fast. Try using HPET for interrupt timing. > >>I don't have visual on the boot sequence anymore (only remote access). > > Use serial console or netconsole. The boot information is logged. Try > dmesg. I am seeing similar results on my Acer Ferrari 4000 (Turion64 ML-37). It does appear that time is running 2x normal time. Booting with noapictimer cleared up the timing issues, though it did introduce some IRQ badness. - -Jeff - -- Jeff Mahoney SuSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDAnPzLPWxlyuTD7IRAuQ+AKCoK4Bvj9YaSxK1cYzK/LQUGcj2pQCgmBKK hGeSfGE+CvdNzqW3pN5LQq8= =wtra -END PGP SIGNATURE- - 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: HDAPS, Need to park the head for real
On Tue, 2005-08-16 at 22:07 +0200, Jens Axboe wrote: > On Tue, Aug 16 2005, Alejandro Bonilla Beeche wrote: > If I were in your position, I would just implement this for ide (pata, > not sata) right now, since that is what you need to support (or do some > of these notebooks come with sata?). So it follows that you add an ide Some notebooks are coming up with a Sata controller I think, but is still and IDE drive. I think some T43's come with that. But, I will ask or check again later if we ever need this feature for SATA. .Alejandro - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
Greg KH wrote: >On Tue, Aug 16, 2005 at 08:34:24AM -0500, Michael E Brown wrote: > > >>On Tue, 2005-08-16 at 01:16 -0700, Greg KH wrote: >> >> >>>No, export this data properly through sysfs like all other temperature >>>and sensor data is. Don't create a new one, no matter how much you >>>would like to keep from changing kernel code in the future for new >>>hardware. >>> >>> >>This driver is not trying to create a new way to do sensor and monitor >>data. This just happens to be a side effect of the main use case. >> >> > >But it's probably a main use case for a lot of users daily experience, >right? > > > No. And after this feedback, I'll be trying to make sure this doesn't happen. There are two main users of this driver (dcdbas) at this point. 1) libsmbios. The main use of this driver by libsmbios will be to set BIOS F2 options. Based on your feedback, I will _NOT_ be implementing any fan/sensor functionality in libsmbios, but will work with the lmsensors guys to do this instead. I only originally mentioned it because I thought it would be useful. My eyes have now been opened as to the best way to do this, and we will do it that way. 2) Dell OpenManage The main use of this driver by openmanage will be to read the System Event Log that BIOS keeps. Here are some other random relevant points: A) The sensor functions available through Dell SMI calls are only on laptops at this point. B) OpenManage is not supported on laptops (server only) C) OpenManage is transistioning to use openipmi to do all sensor-related stuff, so there is no need to use SMI. All this adds up to the fact that neither of the two official Dell apps that use this Dell SMI driver will be using this driver for _ANY_ type of sensor functionality, and there is no danger at all of either of these apps ever growing this functionality. So out of the many SMI functions available for use using this driver, only about 3 or 4 would be commonly used officially by Dell. In the meantime, as a community service, I have offered up libsmbios to document the other many functions available using SMI to anybody who thought they would be useful (as several people have privately emailed me). Based on the availability of this extra functionality (sensors) the whole submission of dcdbas driver is being questioned. I would like to re-iterate at this point what I said in one of my first emails. Everything that you can do using this dcdbas driver can already be done "under the covers" in userspace with the right incantations. (ie. set processor affinity, pick a BIOS reserved area as your physical buffer). What you get by using the dcdbas driver is an auditable entry point in the kernel for anybody wanting to do one of these SMI calls. If the dcdbas driver is accepted, all Dell software that does SMIs will use it. Then, anybody who is curious about which SMI calls that Dell software is performing can simply add logging hooks to dcdbas to syslog the contents of each buffer passed. People who think they are making things "safer" by restricting userspace access to SMIs are only deluding themselves. For example, we already have at least one buggy implementation of this exact stack in the kernel as the i8k driver. The i8k driver was reverse- engineered and works, but it does not follow the spec at all, and so is subject to major breakage if the BIOS changes. With dcdbase + libsmbios, we can write this _correctly_, and in such a way that it follows the spec and will not break on BIOS updates. >>>No, fix the i8k driver as you have access to the specs. It was there >>>first. >>> >>> >>Ok. >> >> > >On second thought, after looking at that code, forget it, just do >something new with the proper hwmon interface instead. > > Ok. Each function would have to take into account the specific calling requirements of that specific function. >>>Again, no different from any other sensor driver. >>> >>> >>Again, this driver is not a sensor driver. >> >> > >You provide sensor data, hence... > > > I cannot go back and undo the way BIOS has designed this interface. It just so happens that by providing a generic way to get the data I want, you also can get at some other, unrelated stuff. We promise we won't use this interface to get that unrelated stuff, (as silly as that sounds). >>For some odd reason, our customers have less concerns with updating a >>userspace library. >> >> > >For a library like this, they should be just as concerned, as you have a >direct hook into their hardware, with the ability to break it just as >easily as a kernel update. > > > Not really. None of the SMI calls that I am aware of has any ability to affect the running of the system with the exception of the Radio control and Display switching calls. It would most likely be best to give the docs for these to the appropriate driver
Re: 2.6.12.3 clock drifting twice too fast (amd64)
On 8/16/05, john stultz <[EMAIL PROTECTED]> wrote: > On Tue, 2005-08-16 at 12:10 +0200, jerome lacoste wrote: > > Installed stock 2.6.12.3 on a brand new amd64 box with an Asus extreme > > AX 300 SE/t mainboard. > > > > I remember seeing a message in the boot saying something along: > > > > "cannot connect to hardware clock." > > > > And now I see that the time is changing too fast (about 2 seconds each > > second). > [snip] > > :00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5951 > > Looks like the AMD/ATI bug. > > http://bugzilla.kernel.org/show_bug.cgi?id=3927 Sounds like it. I will have to try the patch. Good catch John! Jerome - 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: udev-067 and 2.6.12?
On Tue, Aug 16, 2005 at 03:14:50PM -0700, Greg KH wrote: > On Tue, Aug 16, 2005 at 11:12:26PM +0100, Alistair John Strachan wrote: > > On Tuesday 16 August 2005 23:05, Greg KH wrote: > > > On Tue, Aug 16, 2005 at 11:02:00PM +0100, Alistair John Strachan wrote: > > > > Hi, > > > > > > > > I just tried upgrading udev 053 to 067 on a 2.6.12 system and although > > > > the system booted, firmware_class failed to upload the firmware for my > > > > wireless card, prism54 was no longer auto loaded, etc. Even manually > > > > loading the driver didn't help. > > > > > > > > Any reason why 067 wouldn't work with 2.6.12? Do you have to do > > > > something > > > > special with hotplug prior to upgrading? > > > > > > What distro are you using? What rules file are you using? > > > > > > 067 should work just fine for you, it is for a lot of Gentoo and SuSE > > > users right now, on 2.6.12. > > > > > > > An LFS from April 05, with the stock 50-udev.rules, 25-lfs.rules (which > > doesn't do anything suspicious, I think; certainly nothing related to my > > problem). > > There are no "stock" udev rules anymore. That's probably the issue, all > of the distros made their own, so we provide them in the tarball. I > suggest you talk to the LFS people about this. > > > 25-lfs.rules does duplicate some of the things in 50-udev.rules, but I > > think > > that's deliberate (they want to interfere with the stock install as little > > as > > possible, and the overrides take precedence). I've put my /etc/udev > > directory > > unmodified up here: > > > > http://devzero.co.uk/~alistair/udev/ > > s/=/==/ for most of your rules and see if that works. > > > If I reinstall 053 and reboot, everything that's broken on 067 works again. > > Do > > you need a specific hotplug installed? Do you provide hooks for handling /etc/hotplug.d/? We are on the way of getting rid of that directory and recent udev versions don't handle that by default anymore. If you don't know, read the udev RELEASE-NOTES. Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix mmap_kmem (was: [question] What's the difference between /dev/kmem and /dev/mem)
On Maw, 2005-08-16 at 17:12 -0500, Greg Edwards wrote: > mmap_mem suffers from a lack of proper checks as well. For example, on > Altix page 0 of each node is reserved for prom and a read or write to it > will cause an MCA. mmaping /dev/mem with offset 0 will nicely explode. > Would adding a pfn_valid test in mmap_mem be the best bet, or could we > consolidate the checks currently in mmap_kmem into mmap_mem? If you use /dev/mem you should know what you are doing. Even with "checks" dd if=/dev/zero of=/dev/mem will do bad things. Trapping obviously bad cases is fine, but complete sanity checking may actually be counter productive. - 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: [UPDATE PATCH] push rounding up of relative request to schedule_timeout()
On 04.08.2005 [09:45:55 -0700], George Anzinger wrote:
> Uh... PLEASE tell me you are NOT changing timespec_to_jiffies() (and
> timeval_to_jiffies() to add 1. This is NOT the right thing to do. For
> repeating times (see setitimer code) we need the actual time as we KNOW
> where the jiffies edge is in the repeating case. The +1 is needed ONLY
> for the initial time, not the repeating time.
>
>
> See:
> http://marc.theaimsgroup.com/?l=linux-kernel=112208357906156=2
I followed that thread, George, but I think it's a different case with
schedule_timeout() [maybe this indicates drivers/other users should
maybe be using itimers, but I'll get to that in a sec].
With schedule_timeout(), we are just given a relative jiffies value. We
have no context as to which task is requesting the delay, per se,
meaning we don't (can't) know from the interface whether this is the
first delay in a sequence, or a brand new one, without changing all
users to have some sort of control structure. The callers of
schedule_timeout() don't even get a pointer to the timer added
internally.
So, adding 1 to all sleeps seems like it might be reasonable, as looping
sleeps probably need to use a different interface. I had worked a bit
ago on something like poll_event() with the kernel-janitors group, which
would abstract out the repeated sleeps. Basically wait_event() without
wait-queues... Maybe we could make such an interface just use itimers?
I've attached my old patch for poll_event(), just for reference.
My point, I guess, is that in the schedule_timeout() case, we don't know
where the jiffies edge is, as we either expire or receive a wait-queue
event/signal, we never mod_timer() the internal timer... So we have to
assume that we need to sleep the request. But maybe Roman's idea of
sleeping a certain number of jiffy edges is sufficient. I am not yet
convinced driver authors want/need such an interface, though, still
thinking it over.
Thanks for all the feedback,
Nish
--- 2.6.11-kj-v/include/linux/delay.h 2005-03-01 23:37:51.0 -0800
+++ 2.6.11-kj/include/linux/delay.h 2005-03-04 16:03:24.0 -0800
@@ -47,4 +47,106 @@ static inline void ssleep(unsigned int s
msleep(seconds * 1000);
}
+/*
+ * poll_event* check if an @condition is true every @interval milliseconds,
+ * up to a @timeout maximum, if specified, else forever.
+ * The *_interruptible versions will sleep in TASK_INTERRUPTIBLE
+ * (instead of TASK_UNINTERRUPTIBLE) and will return early on signals
+ * Note that these interfaces are distinctly different than
+ * wait_event*() in two ways:
+ * 1) No wait-queues
+ * 2) Specify the time you want to sleep, not when you want to
+ * wake-up. Thus, callers should not add the current time to
+ * @timeout before calling, as it will be done by the macro.
+ */
+
+/**
+ * poll_event - check a condition at regular intervals
+ * @condition: Condition to check
+ * @interval: Number of milliseconds between checks
+ */
+#define poll_event(condition, interval)\
+do { \
+ while (!(condition))\
+ msleep(interval); \
+} while(0)
+
+/**
+ * poll_event_timeout - check a condition at regular intervals with a timeout
+ * @condition: Condition to check
+ * @interval: Number of milliseconds between checks
+ * @timeout: Maximum total number of milliseconds to take
+ * returns: 0, if condition caused return
+ * -ETIME, if timeout
+ */
+#define poll_event_timeout(condition, interval, timeout) \
+({ \
+ int __ret = 0; \
+ unsigned long stop = jiffies + msecs_to_jiffies(timeout); \
+ \
+ for (;;) { \
+ if (condition) \
+ break; \
+ msleep(interval); \
+ if (time_after(jiffies, stop)) {\
+ __ret = -ETIME; \
+ break; \
+ } \
+ } \
+ __ret; \
+})
+
+/**
+ * poll_event_interruptible - check a condition at regular intervals,
returning early on signals
+ * @condition: Condition to check
+ * @interval: Number of milliseconds between checks
+ * returns: 0, if condition caused return
+ * -EINTR, if a signal
+ */
+#define
Re: [Pcihpd-discuss] [PATCH] use bus_slot number for name
On Wed, 2005-08-10 at 16:01 +0100, Matthew Wilcox wrote: > On Fri, Aug 05, 2005 at 12:16:06PM -0700, Kristen Accardi wrote: > > For systems with multiple hotplug controllers, you need to use more than > > just the slot number to uniquely name the slot. Without a unique slot > > name, the pci_hp_register() will fail. This patch adds the bus number > > to the name. > > That doesn't make much sense. The slot number should at least be unique > to the chassis, if not to the whole machine. HP's large machines with > multiple cabinets encode the cabinet number in the return from _SUN. > It ends up as something like 80103 for a large machine while still being > merely slot 3 for the smaller machines. > > IOW, I think this is a firmware bug which needs to be fixed there. > Just wanted to let you know that I'm not ignoring your comment :). I'm checking now to see if the firmware is required to make the slot number unique across all controllers. I also am expecting a hardware/firmware update for the machine that exhibited this behavior, and so will retest when I get it and let you know. although, I'm not sure if it's a good idea to trust the BIOS to do this properly even if it's required. - 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: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote: > On Sul, 2005-08-14 at 13:44 +0100, Daniel Drake wrote: > > > [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, > > > CHS=24321/255/63, BUG > > Thats probably the fact other patches from -ac are missing in base. It > should be harmless. Just remembered that I was seeing the above with 11ac7 aswell. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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/
Representatives needed urgently
Dear Sir/Madam, I am Mr.kim Lee ,we are a company that deal on importing and exporting raw materials into Canada,America and England. We are searching for representatives who can help us establish a medium of getting to our costumers in the Canada,America and England as well as making payments through you to us. Please if you are interested in transacting business with us we will be very glad. Please contact us for more information. Subject to your satisfaction,you shall be well compensated for your troubles and time. reply to [EMAIL PROTECTED] Regards. kim 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: [PATCH] Don't use a klist for drivers' set-of-devices
On 8/15/05, Alan Stern <[EMAIL PROTECTED]> wrote: > On the face of it, neither is particularly more attractive than the other. > However, reading through the various places that call these routines (for > example, drivers/input/serio/serio.c or drivers/pnp/card.c) revealed a > pattern. In most cases, the callers of device_bind_driver _really_ want > something that functions more like driver_probe_device but without the > matching step. The callers are invoking the probe methods by hand rather > than relying on the driver core to do so. There's maybe only one place > where a caller actually does want the device bound to the driver without > doing a probe. > Alan, I am sorry I don't have time to properly review the patch at themoment, just a couple of comments about serio - I would not look at serio for examples of typical use as it was trying very hard to work around the original driver model limitation that prevented drivers to register childern on the same bus from their probe function. I think now that that limitation is lifted serio implemenation can be simplified. -- 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/
Representatives needed urgently
Dear Sir/Madam, I am Mr.kim Lee ,we are a company that deal on importing and exporting raw materials into Canada,America and England. We are searching for representatives who can help us establish a medium of getting to our costumers in the Canada,America and England as well as making payments through you to us. Please if you are interested in transacting business with us we will be very glad. Please contact us for more information. Subject to your satisfaction,you shall be well compensated for your troubles and time. reply to [EMAIL PROTECTED] Regards. kim 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: [rfc][patch] API for timer hooks
On 8/16/05, Stas Sergeev <[EMAIL PROTECTED]> wrote: > Hello. > > john stultz wrote: > > Interesting. Could you explain why the soft-timer interface doesn't<> > > suffice? > I'll try to explain why *I think* > it doesn't suffice, please correct > me if my assumptions are wrong. > > There are two (bad) things about the > PC-Speaker driver: > 1. It needs the higher interrupt frequency. > Since there seem to be no API to change > the timer frequency at runtime, the driver > does this itself. Now I have googled out > the thread > [PATCH] i386: Selectable Frequency of the Timer Interrupt > but it doesn't look like it ended up > with some patch applied, or where is it? This thread resulted in CONFIG_HZ. You get to choose between 100, 250 or 1000. It was not meant to allow runtime HZ modifications. > 2. It needs its handler to be executed > first in the chain. Otherwise the quality > is poor because of the latency. Yeah, that's a tougher one :) > My approach solves both problems by > introducing the grabbing ability. > This is a rather simple patch, and since > it allows to do some cleanup, I though > it could be usefull not only for the > speaker driver. > But if you can tell me how to achieve > at least the point 1 (that is, speed up the > timer at run-time quite arbitrary) without > the kernel mods, then it would be a real > salvation. Does the dynamic-tick patch help you at all? I'm not sure if it's meant to, admittedly. I'm also not sure if it has any cap on the maximum HZ it attempts to reprogram the hardware to... Mucking with HZ at run-time is going to break lots of stuff, though...well, not necessarily, depends on how you muck with jiffies :) Thanks, Nish - 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 5/7] PCI: update documentation
From: Jiri Slaby <[EMAIL PROTECTED]> This removes very old functions from pci docs, which aren't no longer in the kernel. Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- Documentation/pci.txt | 14 -- 1 files changed, 14 deletions(-) --- gregkh-2.6.orig/Documentation/pci.txt 2005-08-16 14:51:30.0 -0700 +++ gregkh-2.6/Documentation/pci.txt2005-08-16 14:57:58.0 -0700 @@ -266,20 +266,6 @@ port an old driver to the new PCI interf in the kernel as they aren't compatible with hotplug or PCI domains or having sane locking. -pcibios_present() and Since ages, you don't need to test presence -pci_present() of PCI subsystem when trying to talk to it. - If it's not there, the list of PCI devices - is empty and all functions for searching for - devices just return NULL. -pcibios_(read|write)_* Superseded by their pci_(read|write)_* - counterparts. -pcibios_find_* Superseded by their pci_get_* counterparts. -pci_for_each_dev() Superseded by pci_get_device() -pci_for_each_dev_reverse() Superseded by pci_find_device_reverse() -pci_for_each_bus() Superseded by pci_find_next_bus() pci_find_device() Superseded by pci_get_device() pci_find_subsys() Superseded by pci_get_subsys() pci_find_slot()Superseded by pci_get_slot() -pcibios_find_class() Superseded by pci_get_class() -pci_find_class() Superseded by pci_get_class() -pci_(read|write)_*_nodev() Superseded by pci_bus_(read|write)_*() -- - 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 1/7] Driver core: potentially fix use after free in class_device_attr_show
From: Maneesh Soni <[EMAIL PROTECTED]>
o moves the code to free devt_attr from class_device_del() to
class_dev_release() which is called after the last reference to the
corresponding kobject() is gone. This allows to keep the devt_attr
alive while the corresponding sysfs file is open.
Signed-off-by: Maneesh Soni <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/base/class.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
--- gregkh-2.6.orig/drivers/base/class.c2005-08-16 14:51:44.0
-0700
+++ gregkh-2.6/drivers/base/class.c 2005-08-16 14:56:58.0 -0700
@@ -299,6 +299,11 @@ static void class_dev_release(struct kob
pr_debug("device class '%s': release.\n", cd->class_id);
+ if (cd->devt_attr) {
+ kfree(cd->devt_attr);
+ cd->devt_attr = NULL;
+ }
+
if (cls->release)
cls->release(cd);
else {
@@ -591,11 +596,8 @@ void class_device_del(struct class_devic
if (class_dev->dev)
sysfs_remove_link(_dev->kobj, "device");
- if (class_dev->devt_attr) {
+ if (class_dev->devt_attr)
class_device_remove_file(class_dev, class_dev->devt_attr);
- kfree(class_dev->devt_attr);
- class_dev->devt_attr = NULL;
- }
class_device_remove_attrs(class_dev);
kobject_hotplug(_dev->kobj, KOBJ_REMOVE);
--
-
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/7] fixes for 2.6.13-rc6
Here are a series of patches against 2.6.13-rc6 that fix a few minor bugs in the driver core, USB, and PCI subsystems. thanks, greg k-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/
[patch 6/7] USB: fix usb wacom tablet driver bug
From: Ping Cheng <[EMAIL PROTECTED]>
This patch fixes bug 4905 and a Cintiq 21UX bug.
Signed-off-by: Ping Cheng <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/input/wacom.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
--- gregkh-2.6.orig/drivers/usb/input/wacom.c 2005-08-16 14:51:29.0
-0700
+++ gregkh-2.6/drivers/usb/input/wacom.c2005-08-16 14:58:01.0
-0700
@@ -342,9 +342,6 @@ static void wacom_graphire_irq(struct ur
goto exit;
}
- x = le16_to_cpu(*(__le16 *) [2]);
- y = le16_to_cpu(*(__le16 *) [4]);
-
input_regs(dev, regs);
if (data[1] & 0x10) { /* in prox */
@@ -373,15 +370,17 @@ static void wacom_graphire_irq(struct ur
}
}
- if (data[1] & 0x80) {
+ if (data[1] & 0x90) {
+ x = le16_to_cpu(*(__le16 *) [2]);
+ y = le16_to_cpu(*(__le16 *) [4]);
input_report_abs(dev, ABS_X, x);
input_report_abs(dev, ABS_Y, y);
- }
- if (wacom->tool[0] != BTN_TOOL_MOUSE) {
- input_report_abs(dev, ABS_PRESSURE, le16_to_cpu(*(__le16 *)
[6]));
- input_report_key(dev, BTN_TOUCH, data[1] & 0x01);
- input_report_key(dev, BTN_STYLUS, data[1] & 0x02);
- input_report_key(dev, BTN_STYLUS2, data[1] & 0x04);
+ if (wacom->tool[0] != BTN_TOOL_MOUSE) {
+ input_report_abs(dev, ABS_PRESSURE,
le16_to_cpu(*(__le16 *) [6]));
+ input_report_key(dev, BTN_TOUCH, data[1] & 0x01);
+ input_report_key(dev, BTN_STYLUS, data[1] & 0x02);
+ input_report_key(dev, BTN_STYLUS2, data[1] & 0x04);
+ }
}
input_report_key(dev, wacom->tool[0], data[1] & 0x10);
@@ -568,7 +567,7 @@ static void wacom_intuos_irq(struct urb
/* Cintiq doesn't send data when RDY bit isn't set */
if ((wacom->features->type == CINTIQ) && !(data[1] & 0x40))
- return;
+ goto exit;
if (wacom->features->type >= INTUOS3) {
input_report_abs(dev, ABS_X, (data[2] << 9) | (data[3] << 1) |
((data[9] >> 1) & 1));
--
-
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/7] PCI: 6700/6702PXH quirk
From: Kristen Accardi <[EMAIL PROTECTED]>
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together. This patch will
prevent MSI from being enabled for the SHPC as part of an early pci
quirk, as well as on any pci device which sets the no_msi bit.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/msi.c |5 -
drivers/pci/pci.h |2 +-
drivers/pci/quirks.c| 21 +
include/linux/pci.h |3 ++-
include/linux/pci_ids.h |5 +
5 files changed, 33 insertions(+), 3 deletions(-)
--- gregkh-2.6.orig/drivers/pci/msi.c 2005-08-16 14:51:31.0 -0700
+++ gregkh-2.6/drivers/pci/msi.c2005-08-16 14:57:12.0 -0700
@@ -453,7 +453,7 @@ static void enable_msi_mode(struct pci_d
}
}
-static void disable_msi_mode(struct pci_dev *dev, int pos, int type)
+void disable_msi_mode(struct pci_dev *dev, int pos, int type)
{
u16 control;
@@ -699,6 +699,9 @@ int pci_enable_msi(struct pci_dev* dev)
if (!pci_msi_enable || !dev)
return status;
+ if (dev->no_msi)
+ return status;
+
temp = dev->irq;
if ((status = msi_init()) < 0)
--- gregkh-2.6.orig/drivers/pci/pci.h 2005-08-16 14:51:31.0 -0700
+++ gregkh-2.6/drivers/pci/pci.h2005-08-16 14:57:12.0 -0700
@@ -46,7 +46,7 @@ extern int pci_msi_quirk;
#else
#define pci_msi_quirk 0
#endif
-
+void disable_msi_mode(struct pci_dev *dev, int pos, int type);
extern int pcie_mch_quirk;
extern struct device_attribute pci_dev_attrs[];
extern struct class_device_attribute class_device_attr_cpuaffinity;
--- gregkh-2.6.orig/drivers/pci/quirks.c2005-08-16 14:55:51.0
-0700
+++ gregkh-2.6/drivers/pci/quirks.c 2005-08-16 14:57:12.0 -0700
@@ -1291,6 +1291,27 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH,
quirk_pcie_mch );
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH,
quirk_pcie_mch );
+
+/*
+ * It's possible for the MSI to get corrupted if shpc and acpi
+ * are used together on certain PXH-based systems.
+ */
+static void __devinit quirk_pcie_pxh(struct pci_dev *dev)
+{
+ disable_msi_mode(dev, pci_find_capability(dev, PCI_CAP_ID_MSI),
+ PCI_CAP_ID_MSI);
+ dev->no_msi = 1;
+
+ printk(KERN_WARNING "PCI: PXH quirk detected, "
+ "disabling MSI for SHPC device\n");
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHD_0,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHD_1,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_0,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_1,
quirk_pcie_pxh);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXHV,
quirk_pcie_pxh);
+
+
static void __devinit quirk_netmos(struct pci_dev *dev)
{
unsigned int num_parallel = (dev->subsystem_device & 0xf0) >> 4;
--- gregkh-2.6.orig/include/linux/pci.h 2005-08-16 14:55:51.0 -0700
+++ gregkh-2.6/include/linux/pci.h 2005-08-16 14:57:37.0 -0700
@@ -556,7 +556,8 @@ struct pci_dev {
/* keep track of device state */
unsigned intis_enabled:1; /* pci_enable_device has been called */
unsigned intis_busmaster:1; /* device is busmaster */
-
+ unsigned intno_msi:1; /* device may not use msi */
+
u32 saved_config_space[16]; /* config space saved at
suspend time */
struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM
entry */
int rom_attr_enabled; /* has display of the rom attribute
been enabled? */
--- gregkh-2.6.orig/include/linux/pci_ids.h 2005-08-16 14:51:31.0
-0700
+++ gregkh-2.6/include/linux/pci_ids.h 2005-08-16 14:57:12.0 -0700
@@ -2281,6 +2281,11 @@
#define PCI_VENDOR_ID_INTEL0x8086
#define PCI_DEVICE_ID_INTEL_EESSC 0x0008
#define PCI_DEVICE_ID_INTEL_21145 0x0039
+#define PCI_DEVICE_ID_INTEL_PXHD_0 0x0320
+#define PCI_DEVICE_ID_INTEL_PXHD_1 0x0321
+#define PCI_DEVICE_ID_INTEL_PXH_0 0x0329
+#define PCI_DEVICE_ID_INTEL_PXH_1 0x032A
+#define PCI_DEVICE_ID_INTEL_PXHV 0x032C
#define PCI_DEVICE_ID_INTEL_82375 0x0482
#define PCI_DEVICE_ID_INTEL_82424 0x0483
#define PCI_DEVICE_ID_INTEL_82378 0x0484
--
-
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 3/7] PCI: fix quirk-6700-fix.patch
From: Andrew Morton <[EMAIL PROTECTED]>
drivers/built-in.o(.text+0x32c3): In function `quirk_pcie_pxh':
/usr/src/25/drivers/pci/quirks.c:1312: undefined reference to `disable_msi_mode'
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/pci/pci.h |6 ++
1 files changed, 6 insertions(+)
--- gregkh-2.6.orig/drivers/pci/pci.h 2005-08-16 14:57:46.0 -0700
+++ gregkh-2.6/drivers/pci/pci.h2005-08-16 14:57:47.0 -0700
@@ -46,7 +46,13 @@ extern int pci_msi_quirk;
#else
#define pci_msi_quirk 0
#endif
+
+#ifdef CONFIG_PCI_MSI
void disable_msi_mode(struct pci_dev *dev, int pos, int type);
+#else
+static inline void disable_msi_mode(struct pci_dev *dev, int pos, int type) { }
+#endif
+
extern int pcie_mch_quirk;
extern struct device_attribute pci_dev_attrs[];
extern struct class_device_attribute class_device_attr_cpuaffinity;
--
-
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 7/7] USB: usbmon: Copyrights and a typo
From: Pete Zaitcev <[EMAIL PROTECTED]>
Add copyright statements and fix a typo.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/mon/mon_main.c |4 +++-
drivers/usb/mon/usb_mon.h |2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
--- gregkh-2.6.orig/drivers/usb/mon/mon_main.c 2005-06-17 12:48:29.0
-0700
+++ gregkh-2.6/drivers/usb/mon/mon_main.c 2005-08-15 23:40:15.0
-0700
@@ -2,6 +2,8 @@
* The USB Monitor, inspired by Dave Harding's USBMon.
*
* mon_main.c: Main file, module initiation and exit, registrations, etc.
+ *
+ * Copyright (C) 2005 Pete Zaitcev ([EMAIL PROTECTED])
*/
#include
@@ -311,7 +313,7 @@
mondir = debugfs_create_dir("usbmon", NULL);
if (IS_ERR(mondir)) {
- printk(KERN_NOTICE TAG ": debugs is not available\n");
+ printk(KERN_NOTICE TAG ": debugfs is not available\n");
return -ENODEV;
}
if (mondir == NULL) {
--- gregkh-2.6.orig/drivers/usb/mon/usb_mon.h 2005-08-15 23:40:08.0
-0700
+++ gregkh-2.6/drivers/usb/mon/usb_mon.h2005-08-15 23:40:15.0
-0700
@@ -1,5 +1,7 @@
/*
* The USB Monitor, inspired by Dave Harding's USBMon.
+ *
+ * Copyright (C) 2005 Pete Zaitcev ([EMAIL PROTECTED])
*/
#ifndef __USB_MON_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/
[patch 4/7] PCI Hotplug: new contact info
From: Kristen Accardi <[EMAIL PROTECTED]> Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- MAINTAINERS| 12 drivers/pci/hotplug/pciehp.h |2 +- drivers/pci/hotplug/pciehp_core.c |2 +- drivers/pci/hotplug/pciehp_ctrl.c |2 +- drivers/pci/hotplug/pciehp_hpc.c |2 +- drivers/pci/hotplug/pciehp_pci.c |2 +- drivers/pci/hotplug/pciehprm.h |2 +- drivers/pci/hotplug/pciehprm_acpi.c|2 +- drivers/pci/hotplug/pciehprm_nonacpi.c |2 +- drivers/pci/hotplug/pciehprm_nonacpi.h |2 +- drivers/pci/hotplug/shpchp.h |2 +- drivers/pci/hotplug/shpchp_core.c |2 +- drivers/pci/hotplug/shpchp_ctrl.c |2 +- drivers/pci/hotplug/shpchp_hpc.c |2 +- drivers/pci/hotplug/shpchp_pci.c |2 +- drivers/pci/hotplug/shpchprm.h |2 +- drivers/pci/hotplug/shpchprm_acpi.c|2 +- drivers/pci/hotplug/shpchprm_legacy.c |2 +- drivers/pci/hotplug/shpchprm_legacy.h |2 +- drivers/pci/hotplug/shpchprm_nonacpi.c |2 +- drivers/pci/hotplug/shpchprm_nonacpi.h |2 +- 21 files changed, 32 insertions(+), 20 deletions(-) --- gregkh-2.6.orig/drivers/pci/hotplug/pciehp_core.c 2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehp_core.c2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> * */ --- gregkh-2.6.orig/drivers/pci/hotplug/pciehp_ctrl.c 2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehp_ctrl.c2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> * */ --- gregkh-2.6.orig/drivers/pci/hotplug/pciehp.h2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehp.h 2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> * */ #ifndef _PCIEHP_H --- gregkh-2.6.orig/drivers/pci/hotplug/pciehp_hpc.c2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehp_hpc.c 2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> * */ --- gregkh-2.6.orig/drivers/pci/hotplug/pciehp_pci.c2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehp_pci.c 2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> * */ --- gregkh-2.6.orig/drivers/pci/hotplug/pciehprm_acpi.c 2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehprm_acpi.c 2005-08-16 14:57:52.0 -0700 @@ -20,7 +20,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]> * */ --- gregkh-2.6.orig/drivers/pci/hotplug/pciehprm.h 2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehprm.h 2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> * */ --- gregkh-2.6.orig/drivers/pci/hotplug/pciehprm_nonacpi.c 2005-08-16 14:51:31.0 -0700 +++ gregkh-2.6/drivers/pci/hotplug/pciehprm_nonacpi.c 2005-08-16 14:57:52.0 -0700 @@ -23,7 +23,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> + * Send feedback to <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> * */ ---
Re: udev-067 and 2.6.12?
On Tue, Aug 16, 2005 at 11:12:26PM +0100, Alistair John Strachan wrote: > On Tuesday 16 August 2005 23:05, Greg KH wrote: > > On Tue, Aug 16, 2005 at 11:02:00PM +0100, Alistair John Strachan wrote: > > > Hi, > > > > > > I just tried upgrading udev 053 to 067 on a 2.6.12 system and although > > > the system booted, firmware_class failed to upload the firmware for my > > > wireless card, prism54 was no longer auto loaded, etc. Even manually > > > loading the driver didn't help. > > > > > > Any reason why 067 wouldn't work with 2.6.12? Do you have to do something > > > special with hotplug prior to upgrading? > > > > What distro are you using? What rules file are you using? > > > > 067 should work just fine for you, it is for a lot of Gentoo and SuSE > > users right now, on 2.6.12. > > > > An LFS from April 05, with the stock 50-udev.rules, 25-lfs.rules (which > doesn't do anything suspicious, I think; certainly nothing related to my > problem). There are no "stock" udev rules anymore. That's probably the issue, all of the distros made their own, so we provide them in the tarball. I suggest you talk to the LFS people about this. > 25-lfs.rules does duplicate some of the things in 50-udev.rules, but I think > that's deliberate (they want to interfere with the stock install as little as > possible, and the overrides take precedence). I've put my /etc/udev directory > unmodified up here: > > http://devzero.co.uk/~alistair/udev/ s/=/==/ for most of your rules and see if that works. > If I reinstall 053 and reboot, everything that's broken on 067 works again. > Do > you need a specific hotplug installed? You shouldn't. You also might want to take this to the linux-hotplug-devel mailing list, as that's the proper place for udev issues. good luck, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udev-067 and 2.6.12?
On Tuesday 16 August 2005 23:05, Greg KH wrote: > On Tue, Aug 16, 2005 at 11:02:00PM +0100, Alistair John Strachan wrote: > > Hi, > > > > I just tried upgrading udev 053 to 067 on a 2.6.12 system and although > > the system booted, firmware_class failed to upload the firmware for my > > wireless card, prism54 was no longer auto loaded, etc. Even manually > > loading the driver didn't help. > > > > Any reason why 067 wouldn't work with 2.6.12? Do you have to do something > > special with hotplug prior to upgrading? > > What distro are you using? What rules file are you using? > > 067 should work just fine for you, it is for a lot of Gentoo and SuSE > users right now, on 2.6.12. > An LFS from April 05, with the stock 50-udev.rules, 25-lfs.rules (which doesn't do anything suspicious, I think; certainly nothing related to my problem). 25-lfs.rules does duplicate some of the things in 50-udev.rules, but I think that's deliberate (they want to interfere with the stock install as little as possible, and the overrides take precedence). I've put my /etc/udev directory unmodified up here: http://devzero.co.uk/~alistair/udev/ If I reinstall 053 and reboot, everything that's broken on 067 works again. Do you need a specific hotplug installed? -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix mmap_kmem (was: [question] What's the difference between /dev/kmem and /dev/mem)
On Sat, Aug 13, 2005 at 08:18:07PM +0200, Arjan van de Ven wrote: | On Sat, 2005-08-13 at 10:37 -0700, Linus Torvalds wrote: | > Actually, the more I looked at that mmap_kmem() function, the less I liked | > it. Let's get that sucker fixed better first. It's still not wonderful, | > but at least now it tries to verify the whole _range_ of the mapping. | | actually if that is your goal this just isn't enough... assume the | situation of a 1 page "forbidden gap", if you mmap 3 pages with the gap | in the middle then the code you send still doesn't cope. At which | point... it gets messy... mmap_mem suffers from a lack of proper checks as well. For example, on Altix page 0 of each node is reserved for prom and a read or write to it will cause an MCA. mmaping /dev/mem with offset 0 will nicely explode. Would adding a pfn_valid test in mmap_mem be the best bet, or could we consolidate the checks currently in mmap_kmem into mmap_mem? Greg - 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/
