hpet on nforce4/MCP51 in asus a6t
Hello, I have a asus a6t with nforce4/MCP51 chipset. I pass to kernel 2.6.24 32 bit the options acpi_use_timer_override and hpet=force, in this way and the timer IRQ ends up routed as IO-APIC-edge instead of XT-PIC. With acpi_use_timer_override I just get: TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 and it works through the IO-APIC. Instead the hpet is disabled and I just get : Time: acpi_pm clocksource has been installed. Clocksource tsc unstable (delta = -85010975 ns) Is possible to have hpet working also with if the BIOS doesn't support it ? I wish to be personally CC'ed the answers/comments posted to the list in response to my posting. Cecco Tiscali.Fax: ricevi gratis sulla tua email e invii a 12 cent per pagina senza scatto alla risposta http://vas.tiscali.it/fax// -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Guadagna con il tuo sito web
Ti piace l' idea di creare una rendita dal tuo sito web? E'possibile senza spese e senza rischi. Ci sono varie agenzie che ti forniscono infatti pubblicit� da inserire nel tuo sito e che ti pagano ogni volta che un utente compie una determinata azione (clicca sulla pubblicit�, o magari acquista o si registra presso il sito dell' inserzionista ). NON esiste solo ADSENSE ! leggi l'articolo intero qui <http://larecensione.com/guadagna-con-il-tuo-sito-webiscriviti-ora-e-ti-regaliamo-20-euro/> -- If you do not want to receive any more newsletters, http://dowebmarketing.com/mail/?p=unsubscribe&uid=52b1b36bba467d31b4c9dd2d1fa4c4ba To update your preferences and to unsubscribe visit http://dowebmarketing.com/mail/?p=preferences&uid=52b1b36bba467d31b4c9dd2d1fa4c4ba Forward a Message to Someone http://dowebmarketing.com/mail/?p=forward&uid=52b1b36bba467d31b4c9dd2d1fa4c4ba&mid=17 -- Powered by PHPlist, www.phplist.com -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Len Brown ha scritto: On Sunday 21 October 2007 05:43, [EMAIL PROTECTED] wrote: have emerged lm_sensors but can't get it running - it keeps saying "No sensors found!" and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. In this case, getting sensors installed is the opposite of what you want to do. The idea is to simplify the system until it works, then figure out what simplification made it work. ie. disable sensors entirely by building a kernel with CONFIG_HWMON=n If that makes things work, then it is a clue. If that was disabled already, then just keep it disabled. It is disabled since when I abandoned the lm_sensors approach; I remember that I did some more testing with lm_sensors and got almost all chips identified, although didn't know how to use lm_sensors to generate some useful logs. I agree with you that we have to simplify the system down. Note: when I built kernel 2.6.24-rc3 to see if it is still affected by bug #9147, CONFIG_HWMON was enabled instead (and the problem was verified anyway). I don't recall how that setting got enabled, however I did not enable it manually and I was not enabling lm_sensors support. Best regards, -- Daniele C. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Laptop keyboard unusable when ACPI is active
Len Brown ha scritto: On Thursday 22 November 2007 02:24, [EMAIL PROTECTED] wrote: It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). No, 8740 is not an ACPI issue. http://bugzilla.kernel.org/show_bug.cgi?id=8740#c2 Sorry for the misleading statement; I no more think that it is an ACPI issue. Although I am still curious about the reason of these bugs happening together even on different hardware configurations; maybe a side effect of the same kernel bug? No idea. Best regards, -- Daniele C. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Laptop keyboard unusable when ACPI is active
Hi all, some upates about this issue (see also bug 9147 http://bugzilla.kernel.org/show_bug.cgi?id=9147 ). The 'ac', 'battery' and 'thermal' modules (compiled as stand-alone) do cause the bug; it suffices that one of them (or any set of them) is loaded to trigger the bug either immediately or after some time. If none of them is loaded into memory, the bug does not happen. Also, the 'battery' module does not generate system messages although the problem is equally verified. The 'thermal' module instead, when loaded with 'modprobe thermal', causes the enter key pressed to execute the command to be indefinitively repeated into any terminal. This is currently a perfectly reproducible testcase for bug 9147. The bug has been confirmed by at least another user (with different hardware configuration); please reply for either bug addressing or confirmation. The current known best workaround to this bug is to compile all the above mentioned ACPI modules as stand-alone and to not (auto)load them (loosing their vital functionalities, since we are talking about laptops here, see http://gentoo-wiki.com/HARDWARE_Maxdata_Pro_7000_DX for an example of affected hardware). It is also important to note that this bug always comes with bug 8740 http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also an ACPI issue). Best regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: I am posting this message just to say that this bug is being addressed on the bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=9147 Regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: [EMAIL PROTECTED] ha scritto: Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: IM Kernel Failure 12/11/07
This is the 5th attempt to email you! I keep being Greylisted! I've extracted the minimal info from a zip which may be failing. I've had to send it from my personal Tiscali account. Regards Martin [1.] One line summary of the problem: System crashed the night of Monday Nov 12 at 22:01 [2.] Full description of the problem/report: There is a cronjob at that time 00 22 * * * . /usr/local/bin/backup_RCP_CVSROOT.sh > /usr/local/bin/cvs_backup.log 2>&1 [3.] Keywords (i.e., modules, networking, kernel): kernel [4.] Kernel version (from /proc/version): Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb 11 00:09:01 EST 2004 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) NO OOPS'ES ! vi ./usr/src/linux-2.4.9-e.3/Documentation/oops-tracing.txt will investigate ... not ... intuitive at first read! [6.] A small shell script or example program which triggers the problem (if possible) N/A [7.] Environment Er ... a Dell box I think! [7.1.] Software (add the output of the ver_linux script here) [EMAIL PROTECTED] /]# sh ./usr/src/linux-2.4.9-e.3/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux pleco.investmaster.com 2.4.9-e.38smp #1 SMP Wed Feb 11 00:09:01 EST 2004 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.11.90.0.8 util-linux 2.11f mount 2.11g modutils 2.4.13 e2fsprogs 1.26 reiserfsprogs 3.x.0j PPP2.4.1 isdn4k-utils 3.1pre1 Linux C Library2.2.4 Dynamic linker (ldd) 2.2.4 Procps 2.0.7 Net-tools 1.60 Console-tools 0.3.3 Sh-utils 2.0.11 Modules Loaded soundcore ide-tape lp parport sr_mod ide-cd cdrom sg esm autofs nfs lockd sunrpc ppp_async ppp_generic slhc tg3 ipchains st usb-ohci usbcore ext3 jbd aic7xxx sd_mod scsi_mod [7.2.] Processor information (from vi /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 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 bogomips: 4757.91 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 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 bogomips: 4771.02 processor : 2 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 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 bogomips: 4771.02 processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 2.40GHz stepping: 9 cpu MHz : 2386.846 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 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 bogomips: 4771.02 [7.3.] Module information (from vi /proc/modules): soundcore 7940 0 (autoclean) ide-tape 61120 0 (autoclean) lp 8192 0 (autoclean) parport38144 0 (autoclean) [lp] sr_mod 17560 0 (autoclean) (unused) ide-cd 35296 0 (autoclean) cdrom 35520 0 (autoclean) [sr_mod ide-cd] sg 35076 0 (autoclean) esm
Re: [PATCH] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote: Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. OK, that's fair. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). I've had this discussion on lkml before. Short story is, until Dell laptops implement the ACPI methods that the backlight API expects, the only sane way to do it is to let libsmbios handle it. Moving the fairly large and complex libsmbios into the kernel isn't a good idea (imho). I agree. The problem is that Dell's DMI tables are not defined in the SMBIOS standard. Thus getting the parameters required for the backlight control (io port, io code, location) needs to be dealt with specifically. Plus DMI is not as comprehensively supported as ACPI is under Linux. I think reading Dell's tables to find out backlight parameters in kernelspace is possible. Unfortunately it would require a significant amount of brand new code to be written. And i'm not sure it is worth the effort. Libsmbios is big and complex because it is written in proficient C++ with lots of OO abstraction. It is also portable. But the task accomplished is simple in principle. jacopo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] backlight dimmer
Ok,
now checkpatch.pl only complains about a missing signed-off-by.
Is this ok for review?
jacopo
--- linux-2.6.23.1/include/linux/backlight.h2007-10-12 18:43:44.0
+0200
+++ b/include/linux/backlight.h 2007-10-28 21:14:21.0 +0100
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/* Notes on locking:
*
@@ -70,6 +71,12 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
+ /* dimmer stuff */
+ struct timeout *timeout;
+ struct input_handler *input_handler;
+ unsigned short dimmer_low_level;
+ unsigned short dimmer_high_level;
+
struct device dev;
};
--- linux-2.6.23.1/drivers/video/backlight/Makefile 2007-10-12
18:43:44.0 +0200
+++ b/drivers/video/backlight/Makefile 2007-10-28 16:42:09.0 +0100
@@ -1,7 +1,7 @@
# Backlight & LCD drivers
obj-$(CONFIG_LCD_CLASS_DEVICE) += lcd.o
-obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
+obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o timeout.o
obj-$(CONFIG_BACKLIGHT_CORGI) += corgi_bl.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
--- linux-2.6.23.1/include/linux/timeout.h 1970-01-01 01:00:00.0
+0100
+++ b/include/linux/timeout.h 2007-10-28 21:14:27.0 +0100
@@ -0,0 +1,68 @@
+/*
+ * timeout.h - simple timeout
+ *
+ *
+ * Copyright (C) 2007 Jacopo Antonello <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#ifndef _TIMEOUT_H_
+#define _TIMEOUT_H_
+
+#include
+#include
+#include
+
+enum timeout_state {
+ TIMEOUT_RUNNING,
+ TIMEOUT_TRIGGERED,
+ TIMEOUT_FINILIZED
+};
+
+struct timeout {
+ /* allow either start() or trigger() at a time */
+ struct mutex lock;
+ /* serialize updates to latest */
+ spinlock_t latest_lock;
+ struct delayed_work trigger_worker;
+ struct work_struct start_worker;
+ unsigned long latest;
+ enum timeout_state state;
+
+ unsigned long duration; /* client defined duration */
+ unsigned long data; /* client data */
+ void (*trigger)(unsigned long); /* client function */
+ void (*start)(unsigned long); /* client function */
+};
+
+extern void timeout_touch(struct timeout *timeout);
+
+extern void timeout_init(struct timeout *timeout);
+
+extern void timeout_kill(struct timeout *timeout);
+
+static inline int timeout_sec2jiffies(int secs)
+{
+ return secs * HZ;
+}
+
+static inline int timeout_jif2sec(unsigned long jif)
+{
+ return jif / HZ;
+}
+
+#endif
--- linux-2.6.23.1/drivers/video/backlight/timeout.c1970-01-01
01:00:00.0 +0100
+++ b/drivers/video/backlight/timeout.c 2007-10-28 21:18:09.0 +0100
@@ -0,0 +1,135 @@
+/*
+ * timeout.c - simple timeout
+ *
+ *
+ * Copyright (C) 2007 Jacopo Antonello <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+
+/* atomic context helpers for timeout->latest */
+static inline unsigned long read_latest(struct timeout *timeout)
+{
+ unsigned long ret;
+ spin_lock(&timeout->latest_lock);
+ ret = timeout->latest;
+ spin_unlock(&timeout->latest_lock);
+ return ret;
+}
+
+static inline unsigned long elapsed(struct timeout *timeout)
+{
+ unsigned long elapsed;
+ spin_lock(&timeout->latest_lock);
+ elapsed = jiffies - timeout->latest;
+ spin_unlock(&timeout->latest_lock);
+
Re: [PATCH] Dell laptop backlight driver
Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). jacopo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] /drivers/ide/pci/piix.c kernel 2.6.23
In piix.c (and in ata_piix.c) are already included some patches to skip the
cable check on some laptops and to enable UDMA>33 modes, but I've noticed than
theese doesn't work on my Acer Aspire 5602WLMi (maybe exist more versions of
this laptop).
With this simple patch i can set transfert mode to UDMA100
--- linux-source-2.6.23/drivers/ide/pci/piix.c 2007-10-09 22:31:38.0
+0200
+++ linux-2.6.23/drivers/ide/pci/piix.c 2007-10-25 22:25:53.0 +0200
@@ -405,6 +405,7 @@
static const struct ich_laptop ich_laptop[] = {
/* devid, subvendor, subdev */
+ { 0x27DF, 0x1025, 0x0102 }, /* ICH7 on Acer 5602aWLMi */
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: > Hi! >> [EMAIL PROTECTED] ha scritto: >> >>> Kernel: 2.6.22-r5 >>> Kernel option: i8042.nomux=1 >>> >> I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: >> >> i8042.nomux=1 acpi=off >> >> I have tried kernel 2.6.23-rc9 but the problem is still there. >> > Try usb keyboard. > The USB keyboard is not affected by the problem, and more importantly it has not the latencies in ACPI mode which the embedded PS2 keyboard has. > Try disabling lm_sensors. > lm_sensors was not installed at all. I have now enabled HWMON and other CONFIG_I2C_* kernel config parameters to use lm_sensors (without success). > Is it smp box? > It is not but from the sensors-detect's log seems like the motherboard supports it. Best regards, -- Daniele - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: > Hi! Hi! >>> Try disabling acpi embedded controller. >>> >>> >> How can I accomplish this? Are you referring to the i8042? >> > > rmmod acpi_ec or how is it called. But I'm not sure how easy this is. > My lsmod doesn't list any acpi module - but I have kacpid, kacpi_listen and hald-addon-acpi processes running. I have compiled the kernel with embedded ACPI support, not modular - maybe that's what you are talking about? > >>> Try watching keyboard interrupts. Are they lost? >>> >>> >> I am pretty sure they are. I think that ACPI pauses interrupts for a >> while (100ms?) and so some keyboard interrupts are lost. >> > input layer can poll keyboard on its own, perhaps that helps? > I am not yet very good at kernel hacking - however yes, it gives me more clues about identifying the issue (see also below link). > Can you try to measure the interrupt latencies? > I will try to do it myself, however somebody else the same problem of mine has already made the tests, please see http://dev.laptop.org/ticket/2401 > Does this happen in init=/bin/bash? > I will perform a test, however the problem rarely verifies in a VT console. I have tried both the kbd and keyboard drivers of X, without any difference. The keyboard problem happens a lot more when plugging in the battery (more ACPI traffic?). I have emerged lm_sensors but can't get it running - it keeps saying "No sensors found!" and complaining about kernel drivers not properly setup. I have attached the output of sensors-detect, from which it seems that the kernel is OK. Thank you, -- Daniele > Pavel > > # sensors-detect revision 4171 (2006-09-24 03:37:01 -0700) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. We can start with probing for (PCI) I2C or SMBus adapters. Do you want to probe now? (YES/no): Y Probing for PCI bus adapters... Use driver `i2c-i801' for device :00:1f.3: Intel 82801DB ICH4 We will now try to load each adapter module in turn. Module `i2c-i801' already loaded. If you have undetectable or unsupported adapters, you can have them scanned by manually loading the modules before running this script. We are now going to do the I2C/SMBus adapter probings. Some chips may be double detected; we choose the one with the highest confidence value in that case. If you found that the adapter hung after probing a certain address, you can specify that address to remain unprobed. Next adapter: SMBus I801 adapter at 1880 Do you want to scan it? (YES/no/selectively): Y Client found at address 0x08 Client found at address 0x1a Probing for `Analog Devices ADM1021'... No Probing for `Analog Devices ADM1021A/ADM1023'...No Probing for `Maxim MAX1617'... No Probing for `Maxim MAX1617A'... No Probing for `TI THMC10'... No Probing for `National Semiconductor LM84'...No Probing for `Genesys Logic GL523SM'... No Probing for `Onsemi MC1066'... No Probing for `Maxim MAX1619'... No Probing for `National Semiconductor LM82/LM83'... No Probing for `Philips Semiconductors PCA9556'... No Client found at address 0x44 Probing for `Maxim MAX6633/MAX6634/MAX6635'... No Client found at address 0x51 Handled by driver `eeprom' (already loaded), chip type `eeprom' Client found at address 0x57 Handled by driver `eeprom' (already loaded), chip type `eeprom' Client found at address 0x69 Some chips are also accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Y Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM78-J' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Probing for `Winbond W83627HF' at 0x290... No Probing for `Silicon Integrated Systems SIS5595'... No Probing for `VIA VT82C686 Integrated Sensors'...No Probing for `VIA VT8231 Integrated Sensors'... No Probing for `AMD K8 thermal sensors'... No Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some Super I/O chips may also contain sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to
Re: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Pavel Machek ha scritto: > Hi! > Hi! Finally an answer, thank you. >> [EMAIL PROTECTED] ha scritto: >> >>> Kernel: 2.6.22-r5 >>> Kernel option: i8042.nomux=1 >>> >> I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: >> >> i8042.nomux=1 acpi=off >> >> I have tried kernel 2.6.23-rc9 but the problem is still there. >> > > Try usb keyboard. > I will get one within 24 hours. > Are you experiencing unusually high latencies in acpi mode? > Yes. > Any unusual activity on top? > Xorg with XFCE4 - it even happens opening up a mousepad and typing something in it. I do not have particular services running, I have apache, mysql and samba. I have installed it on July, so it's a pretty new system - the problem didn't happen before the most recent kernels. > Try disabling lm_sensors. > I will and report here. > Try disabling acpi embedded controller. > How can I accomplish this? Are you referring to the i8042? > Is it smp box? > It is a laptop (Maxdata Pro 7000 DX) with an Intel Centrino 1.6 GhZ (pentium-m), so it is not. > Try watching keyboard interrupts. Are they lost? > I am pretty sure they are. I think that ACPI pauses interrupts for a while (100ms?) and so some keyboard interrupts are lost. See also http://bugzilla.kernel.org/show_bug.cgi?id=9147 I will come up with a test for lm_sensors and the USB keyboard as soon as possible. Thank you very much -- Daniele > Pavel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [irda-users] [PATCH] irlmp_unregister_link needs to free lsaps hashbin
Samuel Ortiz wrote: > Hi Hinko, > > On Fri, Oct 12, 2007 at 02:56:27PM +0200, [EMAIL PROTECTED] wrote: >> Hi, >> >> While testing the mcs7780 based IrDA USB dongle I've stumbled upon >> memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in >> irlmp_register_link and should probably be freed in irlmp_unregister_link(). >> >> Signed-off-by: Hinko Kocevar <[EMAIL PROTECTED]> >> >> Best regards, >> Hinko >> >> >> >> > >> --- linux-2.6.23/net/irda/irlmp.c.orig 2007-10-12 14:05:17.0 >> +0200 >> +++ linux-2.6.23/net/irda/irlmp.c2007-10-12 14:05:41.0 +0200 >> @@ -353,6 +353,7 @@ void irlmp_unregister_link(__u32 saddr) >> /* Final cleanup */ >> del_timer(&link->idle_timer); >> link->magic = 0; >> +hashbin_delete(link->lsaps, (FREE_FUNC) kfree); > Good catch, but I think the right fix sould be: > + hashbin_delete(link->lsaps, (FREE_FUNC) __irlmp_close_lsap); > You're probably right since struct lsap_cb get inserted into the hashbin. Regards, Hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mcs7780 needs to free allocated rx buffer
Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in mcs_net_close(). Patch below fixes it. Signed-off-by: Hinko Kocevar <[EMAIL PROTECTED]> Best regards, Hinko --- linux-2.6.23/drivers/net/irda/mcs7780.c.orig2007-10-12 14:02:55.0 +0200 +++ linux-2.6.23/drivers/net/irda/mcs7780.c 2007-10-12 14:05:03.0 +0200 @@ -678,6 +678,8 @@ static int mcs_net_close(struct net_devi /* Stop transmit processing */ netif_stop_queue(netdev); + kfree_skb(mcs->rx_buff.skb); + /* kill and free the receive and transmit URBs */ usb_kill_urb(mcs->rx_urb); usb_free_urb(mcs->rx_urb);
[PATCH] irlmp_unregister_link needs to free lsaps hashbin
Hi, While testing the mcs7780 based IrDA USB dongle I've stumbled upon memory leak in irlmp_unregister_link(). Hashbin for lsaps is created in irlmp_register_link and should probably be freed in irlmp_unregister_link(). Signed-off-by: Hinko Kocevar <[EMAIL PROTECTED]> Best regards, Hinko --- linux-2.6.23/net/irda/irlmp.c.orig 2007-10-12 14:05:17.0 +0200 +++ linux-2.6.23/net/irda/irlmp.c 2007-10-12 14:05:41.0 +0200 @@ -353,6 +353,7 @@ void irlmp_unregister_link(__u32 saddr) /* Final cleanup */ del_timer(&link->idle_timer); link->magic = 0; + hashbin_delete(link->lsaps, (FREE_FUNC) kfree); kfree(link); } }
Re: Laptop keyboard unusable when ACPI is active
I am posting this message just to say that this bug is being addressed on the bug tracker: http://bugzilla.kernel.org/show_bug.cgi?id=9147 Regards, -- Daniele C. [EMAIL PROTECTED] ha scritto: > [EMAIL PROTECTED] ha scritto: > >> Kernel: 2.6.22-r5 >> Kernel option: i8042.nomux=1 >> > I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: > > i8042.nomux=1 acpi=off > > I have tried kernel 2.6.23-rc9 but the problem is still there. > > >> The problem which still remains, and I can't fix or work it around, is >> witnessed by the below dmesg lines: >> - >> atkbd.c: Unknown key released (translated set 2, code 0xe0 on >> isa0060/serio0). >> atkbd.c: Use 'setkeycodes e060 ' to make it known. >> atkbd.c: Unknown key released (translated set 2, code 0xe0 on >> isa0060/serio0). >> atkbd.c: Use 'setkeycodes e060 ' to make it known. >> atkbd.c: Unknown key released (translated set 2, code 0xe0 on >> isa0060/serio0). >> atkbd.c: Use 'setkeycodes e060 ' to make it known. >> - >> The release event for some keys is never caught, so all sorts of >> troubles happen if for example I use the Del key and it stucks, or if >> I use the Ctrl key and it never gets released...pushing again the >> stuck key brings back the key in the proper status. >> > With acpi=off the problem is totally worked around. > > >> Can somebody please give me some clues about this issue, and possible >> solutions? I have been searching the web for a couple of weeks and >> seems like it is a common trouble of notebook users, but nobody has >> yet published a solution. >> > I am trying to find a path myself in this issue - which dates back to at > least 2005 and has never been resolved. > > I would now try some other kernel parameter in order to preserve ACPI > functionality and possibly prevent ACPI from messing up the keyboard IRQs. > Can somebody please give me istructions regarding the correct tests > (regarding kernel parameters and/or anything else) to perform in order > to better isolate the issue? > > Related Gentoo bug tracker item: > http://bugs.gentoo.org/show_bug.cgi?id=194781 > > Other messages about the same kernel bug (many more can be found > googling around, and no solution yet): > https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html > http://dev.laptop.org/ticket/2401 > > Regards, > -- > Daniele C. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
[EMAIL PROTECTED] ha scritto: > Kernel: 2.6.22-r5 > Kernel option: i8042.nomux=1 I am now using kernel 2.6.22-r8 (Gentoo) and the following kernel options: i8042.nomux=1 acpi=off I have tried kernel 2.6.23-rc9 but the problem is still there. > The problem which still remains, and I can't fix or work it around, is > witnessed by the below dmesg lines: > - > atkbd.c: Unknown key released (translated set 2, code 0xe0 on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e060 ' to make it known. > atkbd.c: Unknown key released (translated set 2, code 0xe0 on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e060 ' to make it known. > atkbd.c: Unknown key released (translated set 2, code 0xe0 on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e060 ' to make it known. > - > The release event for some keys is never caught, so all sorts of > troubles happen if for example I use the Del key and it stucks, or if > I use the Ctrl key and it never gets released...pushing again the > stuck key brings back the key in the proper status. With acpi=off the problem is totally worked around. > Can somebody please give me some clues about this issue, and possible > solutions? I have been searching the web for a couple of weeks and > seems like it is a common trouble of notebook users, but nobody has > yet published a solution. I am trying to find a path myself in this issue - which dates back to at least 2005 and has never been resolved. I would now try some other kernel parameter in order to preserve ACPI functionality and possibly prevent ACPI from messing up the keyboard IRQs. Can somebody please give me istructions regarding the correct tests (regarding kernel parameters and/or anything else) to perform in order to better isolate the issue? Related Gentoo bug tracker item: http://bugs.gentoo.org/show_bug.cgi?id=194781 Other messages about the same kernel bug (many more can be found googling around, and no solution yet): https://lists.linux-foundation.org/pipermail/bugme-new/2005-January/011736.html http://dev.laptop.org/ticket/2401 Regards, -- Daniele C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] softdog - panic instead of reboot, kernel 2.6.22.9
>From Ken Sugawara <[EMAIL PROTECTED]>
Description: Add an option to softdog to panic upon timer expiration
instead of reboot.
Signed-off-by: Ken Sugawara <[EMAIL PROTECTED]>
---
This patch is intended to help increase the chance of postmortem
analysis in the event of silent system hang where it is impossible to
initiate crash dump manually (e.g. no console or network response).
We've had occasions where some of our customers had silent system hang
problems in which they were unable to obtain vmcore for root cause
analysis. Provided that timer interrupts are not blocked, this patch
might enable them to get a crash dump in such a situation by activating
softdog.
--- linux-2.6.22.9/drivers/char/watchdog/softdog.c.orig 2007-09-27
03:03:01.0 +0900
+++ linux-2.6.22.9/drivers/char/watchdog/softdog.c 2007-10-04
12:06:28.0 +0900
@@ -49,6 +49,7 @@
#include
#include
+#include
#define PFX "SoftDog: "
@@ -70,6 +71,11 @@ static int soft_noboot = 0;
module_param(soft_noboot, int, 0);
MODULE_PARM_DESC(soft_noboot, "Softdog action, set to 1 to ignore reboots, 0
to reboot (default depends on ONLY_TESTING)");
+static int panic_instead = 0;
+
+module_param(panic_instead, int, 0);
+MODULE_PARM_DESC(panic_instead, "Softdog action, set to 1 to panic instead of
reboot, 0 to reboot (default 0)");
+
/*
* Our timer
*/
@@ -93,8 +99,11 @@ static void watchdog_fire(unsigned long
if (soft_noboot)
printk(KERN_CRIT PFX "Triggered - Reboot ignored.\n");
- else
- {
+ else if (panic_instead) {
+ printk(KERN_CRIT PFX "Initiating panic.\n");
+ panic("Watchdog timer expired.");
+ printk(KERN_CRIT PFX "Panic didn't ?\n");
+ } else {
printk(KERN_CRIT PFX "Initiating system reboot.\n");
emergency_restart();
printk(KERN_CRIT PFX "Reboot didn't ?\n");
@@ -262,7 +271,7 @@ static struct notifier_block softdog_not
.notifier_call = softdog_notify_sys,
};
-static char banner[] __initdata = KERN_INFO "Software Watchdog Timer: 0.07
initialized. soft_noboot=%d soft_margin=%d sec (nowayout= %d)\n";
+static char banner[] __initdata = KERN_INFO "Software Watchdog Timer: 0.07
initialized. soft_noboot=%d soft_margin=%d sec panic_instead=%d (nowayout=
%d)\n";
static int __init watchdog_init(void)
{
@@ -290,7 +299,7 @@ static int __init watchdog_init(void)
return ret;
}
- printk(banner, soft_noboot, soft_margin, nowayout);
+ printk(banner, soft_noboot, soft_margin, panic_instead, nowayout);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Kernel: 2.6.22-r5 Kernel option: i8042.nomux=1 See attached full dmesg for more. I have recently updated my kernel to 2.6.22 and - in the same occasion - changed various options in the kernel .config; I cannot state that the problem have arisen since kernel 2.6.22 but more probably since I enabled ACPI. My recent configuration changes have been also to xorg.conf (regarding GLX and AIGLX), but I have no real clue about what is causing the troubles. It must be a particular combination of kernel options which triggers this faulty scenario. The first problem I had to solve was about the mouse, not working properly: - psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 4 psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. - I fixed it adding i8042.nomux=1 in the kernel options. The problem which still remains, and I can't fix or work it around, is witnessed by the below dmesg lines: - atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xe0 on isa0060/serio0). atkbd.c: Use 'setkeycodes e060 ' to make it known. - The release event for some keys is never caught, so all sorts of troubles happen if for example I use the Del key and it stucks, or if I use the Ctrl key and it never gets released...pushing again the stuck key brings back the key in the proper status. I could not find a pattern for the verification of the problem, it seems to happen at random. I /feel/ that this is still an i8042/ACPI chipset issue (note that I have ipw2100 active when the problem happens; the mouse problem did not happen when ipw2100 was disabled and I think the psmouse.c lines and atkbd.c are someway related). Can somebody please give me some clues about this issue, and possible solutions? I have been searching the web for a couple of weeks and seems like it is a common trouble of notebook users, but nobody has yet published a solution. Thanks, -- Daniele C. Linux version 2.6.22-gentoo-r5 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #4 SMP Wed Sep 12 19:07:11 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1f6e (usable) BIOS-e820: 1f6e - 1f6eb000 (ACPI data) BIOS-e820: 1f6eb000 - 1f70 (ACPI NVS) BIOS-e820: 1f70 - 2000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) 0MB HIGHMEM available. 502MB LOWMEM available. Entering add_active_range(0, 0, 128736) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 128736 HighMem128736 -> 128736 early_node_map[1] active PFN ranges 0:0 -> 128736 On node 0 totalpages: 128736 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 973 pages used for memmap Normal zone: 123667 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI present. ACPI: RSDP 000F6700, 0014 (r0 PTLTD ) ACPI: RSDT 1F6E6557, 0030 (r1 PTLTD Montara 604 LTP0) ACPI: FACP 1F6EAED2, 0074 (r1 INTEL MONTARAG 604 PTL50) ACPI: DSDT 1F6E6A68, 446A (r1 INTEL MONTARAG 604 MSFT 10E) ACPI: FACS 1F6FBFC0, 0040 ACPI: BOOT 1F6EAFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 1F6E6587, 04D9 (r1 INTELGV3Ref 1001 MSFT 10E) ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 3000 (gap: 2000:dec1) Built 1 zonelists. Total pages: 127731 Kernel command line: root=/dev/hda3 vga=0x318 i8042.nomux=1 console=tty1 Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (013fd000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0558000 soft=c0538000 PID hash table entries: 204
[no subject]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]hpet and rtc max_user_freq predefine in Kconfig
I think users should be able to set max_user_freq values for rtc and hpet during kernel configuration. The default value is set to 1024 with this patch. The default value of 64 is really too small for modern multimedia apps. Besides, this patch fixes link on intel hpet spec. Signed-off-by: Milinevsky Dmitry <[EMAIL PROTECTED]> diff -Nupar linux-2.6.22-cfs-19/drivers/char/hpet.c linux-2.6.22-cfs-19.niam/drivers/char/hpet.c --- linux-2.6.22-cfs-19/drivers/char/hpet.c 2007-07-10 20:57:20.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/hpet.c2007-08-02 01:34:54.0 +0300 @@ -44,9 +44,9 @@ /* * The High Precision Event Timer driver. * This driver is closely modelled after the rtc.c driver. - * http://www.intel.com/hardwaredesign/hpetspec.htm + * http://www.intel.com/technology/architecture/hpetspec.htm */ -#defineHPET_USER_FREQ (64) +#defineHPET_USER_FREQ (CONFIG_HPET_MAX_USER_FREQ) #defineHPET_DRIFT (500) #define HPET_RANGE_SIZE1024/* from HPET spec */ diff -Nupar linux-2.6.22-cfs-19/drivers/char/Kconfig linux-2.6.22-cfs-19.niam/drivers/char/Kconfig --- linux-2.6.22-cfs-19/drivers/char/Kconfig2007-07-10 20:57:15.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/Kconfig 2007-08-02 01:33:33.0 +0300 @@ -791,6 +791,13 @@ config RTC To compile this driver as a module, choose M here: the module will be called rtc. +config RTC_MAX_USER_FREQ + int "User interrupt frequency" + depends on RTC + default "1024" + help + Default value of user interrupt frequency(/proc/sys/dev/rtc/max-user-freq). + config SGI_DS1286 tristate "SGI DS1286 RTC support" depends on SGI_IP22 @@ -1022,6 +1029,13 @@ config HPET open selects one of the timers supported by the HPET. The timers are non-periodic and/or periodic. +config HPET_MAX_USER_FREQ + int "User interrupt frequency" + depends on HPET + default "1024" + help + Default value of user interrupt frequency(/proc/sys/dev/hpet/max-user-freq). + config HPET_RTC_IRQ bool "HPET Control RTC IRQ" if !HPET_EMULATE_RTC default n diff -Nupar linux-2.6.22-cfs-19/drivers/char/rtc.c linux-2.6.22-cfs-19.niam/drivers/char/rtc.c --- linux-2.6.22-cfs-19/drivers/char/rtc.c 2007-07-10 20:57:15.0 +0300 +++ linux-2.6.22-cfs-19.niam/drivers/char/rtc.c 2007-08-02 01:33:48.0 +0300 @@ -191,7 +191,7 @@ static int rtc_proc_open(struct inode *i static unsigned long rtc_status = 0; /* bitmapped status byte. */ static unsigned long rtc_freq = 0; /* Current periodic IRQ rate*/ static unsigned long rtc_irq_data = 0; /* our output to the world */ -static unsigned long rtc_max_user_freq = 64; /* > this, need CAP_SYS_RESOURCE */ +static unsigned long rtc_max_user_freq = CONFIG_RTC_MAX_USER_FREQ; /* > this, need CAP_SYS_RESOURCE */ #ifdef RTC_IRQ /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: sound is interrupting with new kernels
On 7/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > could you try CONFIG_HZ_1000 instead of the 250 you are using currently? > Also, please enable CONFIG_SCHED_DEBUG to improve the output of > cfs-debug-info.sh. > > Ingo > Hi, Igno. Sorry for so long response, I hadn't opportunity to reboot machine for new kernel. I've built 2.6.22 with CONFIG_HZ_1000 and CONFIG_PREEMPT - nothing changed =(. Interesting that in Totem(Gnome vp) sound isn't interrupting during video watching. I'll try other kernels later to find out what is working good for my case. In gxine(xine-based) sound is interrupting too! >firstly, could you check whether the ogg123/mpg321 console apps work >without any audio skipping? If they work fine, does Amarok work fine? >(Amarok is an X apps that has a high-quality latency design - most other >X based players are affected by X communication latencies.) I'm not using amarok but audacious. It's seems that's everything is alright with it. I'll send more tests results later. Best wishes! Dima - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: sound is interrupting with new kernels
Hi! Please run this script while using mplayer or audacious http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh No need. I'm testing now pure 2.6.22: my uname is 'Linux niam 2.6.22 #2 Sun Jul 22 13:52:03 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux' and I have described problems with mplayer, but they are not so hard: sound is interrupting for much less time! Usually this case occurs after pause in watching the movie ... for the first time sound is interrupting and then normal flow is restoring. I'll try 2.6.20 later and I'll send a report! Best wishes! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ck1 patches for 2.6.22 and 2.6.20
Hi! I'm not happy with 2.6.22 stability so I want to stay on 2.6.20. Does -ck1 patches for 2.6.22 and 2.6.20 make the same job? Or it's better to backport -ck1 for 2.6.22 to 2.6.20? Thanks for your time! Best regards, Dmitry Milinevsky. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: performance -cfs19 vs. -ck1 for 2.6.22
to help us figure out the nature of the delay, could you do another thing as well: strace -ttt -TTT -f -o firefox.trace.txt -p `pidof firefox-bin` I'll do that!! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: performance -cfs19 vs. -ck1 for 2.6.22
Hi, Ingo! Could you run the following script: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh I'll do that! But a little bit later - I have tested that on my home computer. hm, is there no other workload on the system? Workload: firefox, transmission(torrent client), gnome terminal, music player. Now I think it could be not a scheduler issue but network subsystem ... but I've got such situation on previous kernels and w/o torrent client running. The problem is not in switching tabs in firefox but in _opening_new_url_. I'm not good in Con's patches but are they touching network subsystem? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
performance -cfs19 vs. -ck1 for 2.6.22
Hi, I haven't made special tests to compare 2.6.22-cfs19 and 2.6.22-ck1, but I see performance superiority of 2.6.22-ck1 using my own eyes. Especially in mozilla-firefox ... Using 2.6.22 or 2.6.22-cfs19 my firefox hangs for some time(~4-5 seconds) when I'm trying to open any url, but with 2.6.22-ck1 firefox doesn't hang at all or at least for a second when I have lots of open tabs. What is the reason? Had Con made better scheduler than cfs and O(1) in general kernel? Kernel configuration in 2.6.22, 2.6.22-ck1, 2.6.22-cfs19 is similar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
i2c: pca954x I2C mux driver
2 3 4 5 6 7 8 9 a b c d e f 00: XX XX XX XX XX 08 XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX 4c XX XX XX 50: UU UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX 61 XX XX XX XX XX XX XX 69 XX XX XX XX XX XX 70: 70 XX XX XX XX XX XX XX bus 6: i2cdetect -y 6 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: XX XX XX XX XX 08 XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX 4c XX XX XX 50: UU UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX 61 XX XX XX XX XX XX XX 69 XX XX XX XX XX XX 70: 70 XX XX XX XX XX XX XX Then i think it's all right, both 4c addresses are on virtual buses (on the phisical one there are a UU statement) but a: sensors *-i2c-5-* or: sensors *-i2c-6-* results in: No sensors found! I read that this drive is able to determine if a device is attached to the virtual or the phisical bus and manage to not activate the first one to avoid duplicates, is that true? Is there a way to force the devices attached to the virtual bus to work? Or simply i made a mistake? Thank for the patience and a big thank for your work. -- Scegli infostrada: ADSL gratis per tutta lestate e telefoni senza canone Telecom http://click.libero.it/infostrada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fwd: NPTL
BTW, please do _NOT_ top post! sorry No, a process also contains an address space. Of course .. I ment they are _almoust_ similar. No, that is creating a schedule unit (task) without an address space. Ok, I've already found that in kernel code ... and correctly understood. Surely you need some context switch when switching between runnable contexts. Hm. If the thread is running after it's sister or parent process - you do not have to switich the process context. Is this done in kernel?? Sorry if my thought are idiotic .. I'm a newby and trying to investigate the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NPTL
So I can say that in linux 'thread' == 'process'? Is kernel routine 'kthread' creating a process? I'm just thinking on this subject: if to create 'real threads' - will it increase performance? Should I ever think in this way? When I say 'real thread' - I mean the thread that doen't switch context when it's starting to run. On 7/12/07, David Schwartz <[EMAIL PROTECTED]> wrote: > Hi! > I have a question about NPTL. > Are NPTL are still based on `clone` system call? Yes. > Are NPTL threads are > "processes" internally? No. By definition, all the threads belong to a single process. NPTL threads are based on KSEs (kernel scheduling entities). A non-threaded process is also a KSE. A threaded process is more than one KSEs. All KSE are, obviously, scheduled by the kernel. > Thanks! You're welcome. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
vmware modules with 2.6.22
Hi! I have problem building vmware modules with 2.6.22. During code investigation I've notiesd that vmware modules are using old sk_buff structure / skb->h.raw != skb->nh.raw / how can I modify code to be able to compile it and where can I read migration guide for sk_buff? Thanks! Milinevsky Dmitriy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 NIKON D50 as UMS
This short patch allows NIKON D50 to be mounted as UMS[unusual device] on Linux niam 2.6.22-rc7-cfs-v18 #2 PREEMPT Tue Jul 3 22:35:53 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux, some previous kernels... lsusb -v Bus 001 Device 006: ID 04b0:0409 Nikon Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x04b0 Nikon Corp. idProduct 0x0409 bcdDevice1.00 iManufacturer 1 NIKON iProduct2 NIKON DSC D50 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered Sorry for flood ... but I disappointed where to send this patch. Signed-off-by: Milinevsky Dmitry <[EMAIL PROTECTED]> --- linux-2.6.22-rc7/drivers/usb/storage/unusual_devs.h 2007-07-03 22:54:23.0 +0300 +++ linux-2.6.22-rc7-niam/drivers/usb/storage/unusual_devs.h 2007-07-03 22:35:39.0 +0300 @@ -313,6 +313,13 @@ US_SC_DEVICE, US_PR_DEVICE,NULL, US_FL_NOT_LOCKABLE ), +/* Reported by Milinevsky Dmitry <[EMAIL PROTECTED]> */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + "NIKON", + "NIKON DSC D50", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold <[EMAIL PROTECTED]> */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, "NIKON", - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 NIKON D50 as UMS
This short patch allows NIKON D50 to be mounted as UMS on 2.6.22-rc7, some previous kernels... --- linux-2.6.22-rc7/drivers/usb/storage/unusual_devs.h 2007-07-03 22:54:23.0 +0300 +++ linux-2.6.22-rc7-niam/drivers/usb/storage/unusual_devs.h 2007-07-03 22:35:39.0 +0300 @@ -313,6 +313,13 @@ US_SC_DEVICE, US_PR_DEVICE,NULL, US_FL_NOT_LOCKABLE ), +/* Reported by Niam <[EMAIL PROTECTED]> */ +UNUSUAL_DEV( 0x04b0, 0x0409, 0x0100, 0x0100, + "NIKON", + "NIKON DSC D50", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY), + /* Reported by Andreas Bockhold <[EMAIL PROTECTED]> */ UNUSUAL_DEV( 0x04b0, 0x0405, 0x0100, 0x0100, "NIKON", - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NIKON D50 problem
Hi! Recently I've found out that my camera NIKON D50 can't mount any more. uname -a: "Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux" dmesg: scsi 2:0:0:0: Direct-Access NIKOND50 1.00 PQ: 0 ANSI: 2 sd 2:0:0:0: [sdb] 1984001 512-byte hardware sectors (1016 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] 1984001 512-byte hardware sectors (1016 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete end_request: I/O error, dev sdb, sector 1984000 Buffer I/O error on device sdb, logical block 1984000 end_request: I/O error, dev sdb, sector 1984000 Buffer I/O error on device sdb, logical block 1984000 end_request: I/O error, dev sdb, sector 1983992 Buffer I/O error on device sdb, logical block 1983992 end_request: I/O error, dev sdb, sector 1983993 Buffer I/O error on device sdb, logical block 1983993 Buffer I/O error on device sdb, logical block 1983994 Buffer I/O error on device sdb, logical block 1983995 Buffer I/O error on device sdb, logical block 1983996 Buffer I/O error on device sdb, logical block 1983997 Buffer I/O error on device sdb, logical block 1983998 Buffer I/O error on device sdb, logical block 1983999 end_request: I/O error, dev sdb, sector 1983992 ... Some time ago(I really can't remember version of the kernel) everything was Ok. I'll try to find out the workable version of the kernel ... but I've already tried 2.6.20 - the same =(. I'm not sure, but It's possible that I've had ATA subsystem but not libata ... I haven't tested this case yet. PS. I can see photos on my camera ... flash card is Ok. I have this problem even if I changed the flash card in this camera. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pci hidden behind transparent bridge
Hi! I noticed such message: "PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#06) (try 'pci=assign-busses') Please report the result to linux-kernel to fix this permanently" on my Linux niam 2.6.22-rc6-cfs-v18 #6 Mon Jul 2 20:19:25 EEST 2007 i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux What does it mean?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/2] 2.6.22-rc5: known regressions with patches v2
That would be a bit like waiting for a Debian release and never happen. Ok, but Debian seems to be stable and sometimes their teem make releases =). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/2] 2.6.22-rc5: known regressions with patches v2
We have patches for "very high non-preempt latency in context_struct_compute_av()" and "list_add corruption. prev->next should be next (f7d28794), but was f0df8ed4 (prev=f0df8ed4) Kernel Bug at lib/list_debug.c:33", but both are too intrusive. Anyway, those bugs are not regressions. Are you going to release 2.6.22 with this bugs?? But question wasn't on this subject ... The question was "why linux kernel release should have some bugs that would be fixed fixed in future?" Let's wait and publish kernel w/o known bugs. Let's wait for some time, let's publish 2.6.22-rc_last, test it for some time(2 weeks for example), fix bugs if any and after _test_period_of_whole_kernel_ but not _separate_patches/parts_ of kernel release stable one! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[1/2] 2.6.22-rc5: known regressions with patches v2
Hello! I'm a newbuy in kernel development. Now I'm just trying to find out what is going in it =). I noticed this: (BTW. There is a new category called "Will be fixed in 2.6.23") Is it really important to release 2.6.22 as soon as possible? I think kernel should be 99% stable. Why not to wait for patches on known regressions and release more or less stable 2.6.22? Thanks! Best wishes, Niam. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: V4L2 - Leadtek Winfast PVR 2000 XP makes partial kernel freeze
idia CK804 fc00-fc1f : :00:01.1 cat /proc/iomem: -0009efff : System RAM - : Crash kernel 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000cefff : Video ROM 000f-000f : System ROM 0010-3fed : System RAM 0020-0042a620 : Kernel code 0042a621-0054d1ff : Kernel data 3fee-3fee2fff : ACPI Non-volatile Storage 3fee3000-3fee : ACPI Tables 3fef-3fef : reserved d000-dfff : PCI Bus #05 d000-dfff : :05:00.0 e000-efff : reserved fa00-fcff : PCI Bus #05 fa00-faff : :05:00.0 fa00-faff : nvidia fb00-fbff : :05:00.0 fcfe-fcff : :05:00.0 fd00-fdff : PCI Bus #01 fd00-fdff : :01:07.0 fd00-fdff : cx88[0] fe02a000-fe02afff : :00:0a.0 fe02a000-fe02afff : forcedeth fe02b000-fe02bfff : :00:08.0 fe02b000-fe02bfff : sata_nv fe02c000-fe02cfff : :00:07.0 fe02c000-fe02cfff : sata_nv fe02d000-fe02dfff : :00:04.0 fe02d000-fe02dfff : NVidia CK804 fe02f000-fe02 : :00:02.0 fe02f000-fe02 : ohci_hcd feb0-feb000ff : :00:02.1 feb0-feb000ff : ehci_hcd fec0-fec00fff : IOAPIC 0 fee0-fee00fff : Local APIC [EMAIL PROTECTED]:~$ lspci -vvv 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Capabilities: 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev f3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Interrupt: pin A routed to IRQ 255 Region 0: I/O ports at fc00 [size=32] Region 4: I/O ports at 4c00 [size=64] Region 5: I/O ports at 4c40 [size=64] Capabilities: 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 22 Region 0: Memory at fe02f000 (32-bit, non-prefetchable) [size=4K] Capabilities: 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (750ns min, 250ns max) Interrupt: pin B routed to IRQ 23 Region 0: Memory at feb0 (32-bit, non-prefetchable) [size=256] Capabilities: 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 822c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (500ns min, 1250ns max) Interrupt: pin A routed to IRQ 22 Region 0: I/O ports at f000 [size=256] Region 1: I/O ports at ec00 [size=256] Region 2: Memory at fe02d000 (32-bit, non-prefetchable) [size=4K] Capabilities: 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 (750ns min, 250ns max) Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] Region 4: I/O ports at e800 [size=16] Capabilities: 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controlle
Re: Improved UDP performance using 2.6.21-rc5-rt10
Ingo, Here are some more results: Nvidia w/cyclesoak 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 Nvidia w/top 2.6.21-rc5-rt12 938 31% netperf @51 hardirq @50 softirq @50 Hopefully I'll run some more tests in the morning Thanks, Dave -- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > rt10 shows a big improvement over rt8 > > > > ## > > etupThruput CPU% > > Nvidia > > 2.6.21-rc5-rt8 938 65% > >netperf @51 > >hardirq @50 > >softirq @50 > > > > Nvidia > > 2.6.21-rc5-rt10 938 32% > >netperf @51 > >hardirq @50 > >softirq @50 > > cool! Btw., could you run the same but without running cyclesoak, and > only watching the 'idle' metric in 'top' or vmstat? I found in my > experiments that cyclesoak sometimes interfers with the workload - and > the idle stats are precise and accurate on -rt. (they are not on > vanilla) > > 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: Improved UDP performance using 2.6.21-rc5-rt10
rt10 shows a big improvement over rt8 ## etupThruput CPU% Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Nvidia 2.6.21-rc5-rt10 938 32% netperf @51 hardirq @50 softirq @50 very nice for a "work in progress" I ran the netperf test a few times and one of the times the netperf test would no longer talk to the server. I had to reboot the rt client to get netperf to talk again. I did have cycle soak running which may have contributed to the problem. Also when netperf is not running the hard IRQs associated with the NIC use a constant 2% load. Thanks, Dave -- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * David Sperry <[EMAIL PROTECTED]> wrote: > > > > there are a few other things i'm working on to improve this. I've > > > uploaded -rt9 which is the current state of affairs. Note that using > > > -rt9 you'll likely only see IRQ-8406 overhead in the system, because > > > i've added an optimization to do process the softirq-net-tx workload > > > in the hardirq thread if the priority of the two is the same (which > > > is the default behavior). But -rt9 is still work in progress that is > > > not fully finished yet: in some cases i'm seeing 'fluctuating > > > performance' problems on forcedeth that werent there before. > > > > I tried -rt9 and saw some odd 'fluctuating performance'. I'll try it > > again tomorrow when I am much closer to the box's power button. > > could you try -rt10? I've improved hardirq/softirq threading performance > some more, and have tuned the forcedeth driver too. > > 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: Poor UDP performance using 2.6.21-rc5-rt5
I have a new data point to add to the confusion. The box I'm testing has 2 nics in it. The one I have been testing so far is: 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) The other NIC is an Intel 1gig fiber 09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) The Intel controller did not work 2.6.20 but under 2.6.21-rc5-rt8 it does. Running the same netperf tests with the Intel NIC produces very different results for the RT case: setupThruput CPU% Nvidia 2.6.21-rc5 vanilla 935 29% netperf @51 hardirq @50 softirq @50 Intel 2.6.21-rc5 vanilla 933 30% netperf @51 hardirq @50 softirq @50 ## Nvidia 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 Intel 2.6.21-rc5-rt8 938 34% netperf @51 hardirq @50 softirq @50 The Intel NIC seems to behave better under RT top for each NIC under test yields some interesting results: Nvidia 2.6.21-rc5-rt8: top - 11:03:46 up 1:23, 2 users, load average: 1.75, 1.31, 0.70 Tasks: 167 total, 2 running, 165 sleeping, 0 stopped, 0 zombie Cpu(s): 0.8%us, 29.7%sy, 0.0%ni, 34.8%id, 0.0%wa, 22.1%hi, 10.6%si, 0.0%st Mem: 2035436k total, 618276k used, 1417160k free,31744k buffers Swap: 3068372k total,0k used, 3068372k free, 386060k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 4139 root -52 0 6440 636 480 S 60 0.0 0:19.14 netperf 2706 root -51 -5 000 R 44 0.0 2:00.70 IRQ-8406 19 root -51 0 000 S 21 0.0 0:38.50 softirq-net-tx/ 4012 eadi 16 0 229m 6852 5584 S1 0.3 0:05.39 multiload-apple 6 root -51 0 000 S1 0.0 0:00.95 softirq-net-tx/ 3014 dbus 15 0 21352 896 548 S1 0.0 0:00.04 dbus-daemon 1 root 15 0 10308 668 552 S0 0.0 0:00.74 init 2 root RT 0 000 S0 0.0 0:00.00 migration/0 3 root RT 0 000 S0 0.0 0:00.00 posix_cpu_timer 4 root -51 0 000 S0 0.0 0:00.00 softirq-high/0 5 root -51 0 000 S0 0.0 0:00.00 softirq-timer/0 7 root -51 0 000 S0 0.0 0:00.00 softirq-net-rx/ 8 root -51 0 000 S0 0.0 0:00.01 softirq-block/0 Intel 2.6.21-rc5-rt8 top - 11:10:27 up 3 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 167 total, 1 running, 166 sleeping, 0 stopped, 0 zombie Cpu(s): 0.5%us, 21.6%sy, 0.0%ni, 65.9%id, 0.0%wa, 3.0%hi, 9.0%si, 0.0%st Mem: 2035436k total, 618012k used, 1417424k free,29972k buffers Swap: 3068372k total,0k used, 3068372k free, 386084k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3955 root -52 0 6436 636 480 S 43 0.0 0:19.74 netperf 20 root -51 0 000 S 11 0.0 0:04.86 softirq-net-rx/ 7 root -51 0 000 S7 0.0 0:03.28 softirq-net-rx/ 2370 root -51 -5 000 S6 0.0 0:02.62 IRQ-8408 3858 eadi 16 0 229m 6848 5584 S1 0.3 0:01.45 multiload-apple 3954 eadi 15 0 12712 1096 788 R0 0.1 0:00.19 top 1 root 15 0 10304 664 552 S0 0.0 0:00.75 init 2 root RT 0 000 S0 0.0 0:00.00 migration/0 3 root RT 0 000 S0 0.0 0:00.00 posix_cpu_timer 4 root -51 0 000 S0 0.0 0:00.00 softirq-high/0 5 root -51 0 000 S0 0.0 0:00.00 softirq-timer/0 6 root -51 0 000 S0 0.0 0:00.00 softirq-net-tx/ 8 root -51 0 000 S0 0.0 0:00.01 softirq-block/0 9 root -51 0 000 S0 0.0 0:00.00 softirq-tasklet 10 root -51 0 000 S0 0.0 0:00.00 softirq-sched/0 I think there is some kind of bad behavior happening in the Nvidia driver with respect to softirq-net-tx and IRQ-8406. Any thoughts? If you want I can post the oprofile from both test cases. -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: Poor UDP performance using 2.6.21-rc5-rt5
-- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Thanks for all the input Ingo, Here's a list of all the permutations > > I've tried: > > one thing i noticed is that cyclesoak interferes with the netperf > workload. This is quite surprising. 'top' and 'vmstat' output is > reliable on -rt, and the overhead goes down if i stop cyclesoak. > > Ingo I see the same effect setupThruput CPU% cyclesoak on 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 cyclesoak off 2.6.21-rc5-rt8 938 65% netperf @51 hardirq @50 softirq @50 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: Poor UDP performance using 2.6.21-rc5-rt5
Thanks for all the input Ingo, Here's a list of all the permutations I've tried: setupThruput CPU% from cyclesoak 2.6.21-rc5 vanilla 935 29% 2.6.21-rc5-rt5 711 50% //basically all of 1 cpu 2.6.21-rc5-rt8 733 52% 2.6.21-rc5-rt8 824 64% netperf @50 hardirq @50 softirq @50 2.6.21-rc5-rt8 937 74% netperf @51 hardirq @50 softirq @50 2.6.21-rc5-rt8 106 8% netperf @51 hardirq @49 softirq @50 2.6.21-rc5-rt8 233 14% netperf @51 hardirq @49 softirq @48 2.6.21-rc5-rt8 67 5% netperf @batch hardirq @batch softirq @batch 2.6.21-rc5-rt8 331 OFF netperf @batch hardirq @batch softirq @batch cyclesoak off Any thoughts? -Dave -- Original message -- From: Ingo Molnar <[EMAIL PROTECTED]> > > * Dave Sperry <[EMAIL PROTECTED]> wrote: > > > I checked the clock source and in both the vanilla and rt cases and > > they were both acpi_pm > > ok, thanks for double-checking that. > > > Here's the oprofile for my vanilla case: > > i tried your workload and i think i managed to optimize it some more: i > have uploaded the -rt8 kernel with these improvements included - could > you try it? Is there any measurable improvement relative to -rt5? > > one more thing to improve netperf performance is to do this before > running it: > > chrt -f -p 50 $$ > > this will put netperf on the same priority level as the net hardirq and > the net softirq (which both default to SCHED_FIFO:50), and should result > in a (much) reduced context-switch rate. > > Or, if networking is not latency-critical, then you could move the net > hardirq and softirq threads to SCHED_BATCH, and run netperf under > SCHED_BATCH as well, using: > > chrt -b -p 0 $$ > > and figuring out the active softirq hardirq thread PIDs and "chrt -b" > -ing them too. > > 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: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On 3/3/07, Jean Delvare <[EMAIL PROTECTED]> wrote: Hi Matthew, On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote: > On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote: > > It might be more elegant but it won't work. We don't want to prevent > > ACPI from accessing these I/O ports. If we need to choose only one > > "driver" accessing the I/O port, it must be acpi, at leat for now, > > despite the fact that acpi provides very weak hardware monitoring > > capabilities compared to the specific drivers. > > Assuming arbitration of access, what's the problem with having two > drivers accessing the same hardware? Do these chips generally have any > significant internal state other than trip points and the like? The "assuming arbitration of access" is the key part of your sentence ;) The problem is that currently no arbitration is done. If it was done, then state would probably not be a problem. Most hardware monitoring drivers don't assume any state is preserved between accesses, and those which do can easily be changed not to. The ACPI side is another story though, I guess we can't assume anything about the AML code's assumption on states, as it differs from one machine to the next. But we can try to be cooperative and restore the sensible registers (e.g. bank selector) in the same state we found them. I recall that one of the stated drawbacks of a lock was that no ACPI code could execute while the hwmon driver was doing its fairly lengthy conversation with the hardware. It seems that using transactional concepts here would solve that problem. For example, the hwmon driver issues a start transaction request. The first write request to any given location (bank register for example) causes the previous memory value to be saved. Then, instead of locking AML out, AML is allowed to execute, but any access to the memory/port ranges reserved by the driver (when the transaction is set up) cause the hwmon transaction to be rolled back so the AML sees the expected state. Then AML proceeds as usual. When hwmon tries additional operations, they fail with some "transaction interrupted" error message, indicating to the hwmon driver to start over. The only issue with this that I can see, is that if AML isn['t executed atomically wrt hwmon, then knowing when it is safe for hwmon to retry is going to be difficult. This probably requires changes to every hwmon driver, but they can be updated piecemeal, starting with the ones most commonly found in notebooks, where ACPI is most important. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.19.1: kernel BUG at mm/slab.c:2911!
Christoph Lameter wrote: > On Tue, 30 Jan 2007, Martin MOKREJS wrote: > >> Hi, >> is this a known issue? Should I bother to upgrade to 2.6.19.2 if it >> contains the fix? >> Thank you any help. It might be related to NFS. The machine in question is >> NFSv3 client, >> udp. And used for computations. The process which died is from torque >> cluster management >> package. > >> 000: 00 00 00 00 fe ff ff ff fe ff ff ff 3a 00 00 00 > > The beginning of the slab was overwritten. The first two words should have > been list pointers. color offset is also invalid as is the pointer to the > slab memory. > > Are you using cpu hotplug by chance? No, it is a classical P4 machine, ASUS P4C800E-Deluxe motherboard. However, it might have been related to the overclocked CPU. Although 12 other, exactly same machines are running fine at the same over-clock I have decreased the settings. It did not happen since then. So I believe it was a hardware issue. Thanks for the explanation. Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] mm: fix page_mkclean_one
On Thu Dec 28 15:09 , Guillaume Chazarain sent: >I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/ >I have corruption with every Fedora release kernel except the first, that is >2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit >some corruption. Confirm that I see corruption with Fedora kernel 2.6.18-1.2239.fc5: ... Chunk 142969 corrupted (0-1459) (2580-4039) Expected 121, got 0 Written as (89632)127652(124721) Chunk 142976 corrupted (0-1459) (512-1971) Expected 128, got 0 Written as (121734)128324(108589) Checking chunk 143639/143640 (99%) $ uname -a Linux 2.6.18-1.2239.fc5 #1 Fri Nov 10 13:04:06 EST 2006 i686 athlon i386 GNU/Linux /Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 namespace conflict between w9968cf.c on MIPS
Okay, thanks.
Best regards
Luca Risolia
Scrive Ralf Baechle <[EMAIL PROTECTED]>:
> Both use __SC. Since __* is sort of private namespace I've choosen to
> fix this in the driver. For consistency I decieded to also change
> __UNSC to UNSC.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
>
> diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c
> index ddce2fb..9f403af 100644
> --- a/drivers/media/video/w9968cf.c
> +++ b/drivers/media/video/w9968cf.c
> @@ -1827,8 +1827,8 @@ w9968cf_set_window(struct w9968cf_device
> int err = 0;
>
> /* Work around to avoid FP arithmetics */
> - #define __SC(x) ((x) << 10)
> - #define __UNSC(x) ((x) >> 10)
> + #define SC(x) ((x) << 10)
> + #define UNSC(x) ((x) >> 10)
>
> /* Make sure we are using a supported resolution */
> if ((err = w9968cf_adjust_window_size(cam, (u16*)&win.width,
> @@ -1836,15 +1836,15 @@ w9968cf_set_window(struct w9968cf_device
> goto error;
>
> /* Scaling factors */
> - fw = __SC(win.width) / cam->maxwidth;
> - fh = __SC(win.height) / cam->maxheight;
> + fw = SC(win.width) / cam->maxwidth;
> + fh = SC(win.height) / cam->maxheight;
>
> /* Set up the width and height values used by the chip */
> if ((win.width > cam->maxwidth) || (win.height > cam->maxheight)) {
> cam->vpp_flag |= VPP_UPSCALE;
> /* Calculate largest w,h mantaining the same w/h ratio */
> - w = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh;
> - h = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight;
> + w = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh;
> + h = (fw >= fh) ? SC(win.height)/fw : cam->maxheight;
> if (w < cam->minwidth) /* just in case */
> w = cam->minwidth;
> if (h < cam->minheight) /* just in case */
> @@ -1861,8 +1861,8 @@ w9968cf_set_window(struct w9968cf_device
>
> /* Calculate cropped area manteining the right w/h ratio */
> if (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE)) {
> - cw = (fw >= fh) ? cam->maxwidth : __SC(win.width)/fh;
> - ch = (fw >= fh) ? __SC(win.height)/fw : cam->maxheight;
> + cw = (fw >= fh) ? cam->maxwidth : SC(win.width)/fh;
> + ch = (fw >= fh) ? SC(win.height)/fw : cam->maxheight;
> } else {
> cw = w;
> ch = h;
> @@ -1901,8 +1901,8 @@ w9968cf_set_window(struct w9968cf_device
> /* We have to scale win.x and win.y offsets */
> if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE))
>|| (cam->vpp_flag & VPP_UPSCALE) ) {
> - ax = __SC(win.x)/fw;
> - ay = __SC(win.y)/fh;
> + ax = SC(win.x)/fw;
> + ay = SC(win.y)/fh;
> } else {
> ax = win.x;
> ay = win.y;
> @@ -1917,8 +1917,8 @@ w9968cf_set_window(struct w9968cf_device
> /* Adjust win.x, win.y */
> if ( (cam->largeview && !(cam->vpp_flag & VPP_UPSCALE))
> || (cam->vpp_flag & VPP_UPSCALE) ) {
> - win.x = __UNSC(ax*fw);
> - win.y = __UNSC(ay*fh);
> + win.x = UNSC(ax*fw);
> + win.y = UNSC(ay*fh);
> } else {
> win.x = ax;
> win.y = ay;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [irda-users] Is ircomm possible with smsc_ircc2?
Andrey Borzenkov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have Toshiba Portege 4000, which apparently needs smsc_ircc2 driver. Driver seems to load OK: Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. Activated ALi 1533 ISA bridge port 0x02e8. Activated ALi 1533 ISA bridge port 0x02f8. found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 smsc_superio_flat(): IrDA not enabled smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02 SMsC IrDA Controller found IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7 No transceiver found. Defaulting to Fast pin select and it registers irda0 interface but no /dev/ircomm* ever appears. I need them (or at least I /think/ I need them) for SynCE (for installing programs in my Pocket LOOX). What is missing? Do I need additional driver? How can I access ircomm on this HW? You probably need to load the ircomm-tty and ircomm modules on top of irda stack for /dev/ircomm*. Best regards, hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/10] cxgb3 - offload header files
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the offload operations header files
for the Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_ctl_defs.h | 141
drivers/net/cxgb3/cxgb3_defs.h | 100 +++
drivers/net/cxgb3/cxgb3_offload.h | 199 +
drivers/net/cxgb3/l2t.h| 144
drivers/net/cxgb3/t3_cpl.h | 1431
drivers/net/cxgb3/t3cdev.h | 72 ++
6 files changed, 2087 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_ctl_defs.h
b/drivers/net/cxgb3/cxgb3_ctl_defs.h
new file mode 100644
index 000..be7ac6d
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_ctl_defs.h
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) 2003-2006 Chelsio Communications. All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#ifndef _CXGB3_OFFLOAD_CTL_DEFS_H
+#define _CXGB3_OFFLOAD_CTL_DEFS_H
+
+enum {
+ GET_MAX_OUTSTANDING_WR,
+ GET_TX_MAX_CHUNK,
+ GET_TID_RANGE,
+ GET_STID_RANGE,
+ GET_RTBL_RANGE,
+ GET_L2T_CAPACITY,
+ GET_MTUS,
+ GET_WR_LEN,
+ GET_IFF_FROM_MAC,
+ GET_DDP_PARAMS,
+ GET_PORTS,
+
+ ULP_ISCSI_GET_PARAMS,
+ ULP_ISCSI_SET_PARAMS,
+
+ RDMA_GET_PARAMS,
+ RDMA_CQ_OP,
+ RDMA_CQ_SETUP,
+ RDMA_CQ_DISABLE,
+ RDMA_CTRL_QP_SETUP,
+ RDMA_GET_MEM,
+};
+
+/*
+ * Structure used to describe a TID range. Valid TIDs are [base, base+num).
+ */
+struct tid_range {
+ unsigned int base; /* first TID */
+ unsigned int num;/* number of TIDs in range */
+};
+
+/*
+ * Structure used to request the size and contents of the MTU table.
+ */
+struct mtutab {
+ unsigned int size; /* # of entries in the MTU table */
+ const unsigned short *mtus; /* the MTU table values */
+};
+
+struct net_device;
+
+/*
+ * Structure used to request the adapter net_device owning a given MAC address.
+ */
+struct iff_mac {
+ struct net_device *dev; /* the net_device */
+ const unsigned char *mac_addr; /* MAC address to lookup */
+ u16 vlan_tag;
+};
+
+/*
+ * Structure used to request the TCP DDP parameters.
+ */
+struct ddp_params {
+ unsigned int llimit; /* TDDP region start address */
+ unsigned int ulimit; /* TDDP region end address */
+ unsigned int tag_mask; /* TDDP tag mask */
+};
+
+struct adap_ports {
+ unsigned int nports; /* number of ports on this adapter */
+ struct net_device *lldevs[2];
+};
+
+struct pci_dev;
+
+/*
+ * Structure used to return information to the iscsi layer.
+ */
+struct ulp_iscsi_info {
+ unsigned intoffset;
+ unsigned intllimit;
+ unsigned intulimit;
+ unsigned inttagmask;
+ unsigned intpgsz3;
+ unsigned intpgsz2;
+ unsigned intpgsz1;
+ unsigned intpgsz0;
+ unsigned intmax_rxsz;
+ unsigned intmax_txsz;
+ struct pci_dev *pdev;
+};
+
+/*
+ * Structure used to return information to the RDMA layer.
+ */
+struct rdma_info {
+ unsigned int tpt_base; /* TPT base address */
+ unsigned int tpt_top;/* TPT last entry address */
+ unsigned int pbl_base; /* PBL base address */
+ unsigned int pbl_top;/* PBL last entry address */
+ unsigned int rqt_base; /* RQT base address */
+ unsigned int rqt_top;/* RQT last entry address */
+ unsigned int udbell_len; /* user doorbell region length */
+ unsigned long udbell_physbase; /* user doorbell physical start addr */
+ void __iomem *kdb_addr; /* kernel doorbell register address */
+ struct pci_dev *pdev;/* associated PCI device */
+};
+
+/*
+ * Structure used to request an operation on an RDMA completion queue.
+ */
+struct rdma_cq_op {
+ unsigned int id;
+ unsigned int op;
+ unsigned int credits;
+};
+
+/*
+ * Structure used to setup RDMA completion queues.
+ */
+struct rdma_cq_setup {
+ unsigned int id;
+ unsigned long long base_addr;
+ unsigned int size;
+ unsigned int credits;
+ unsigned int credit_thres;
+ unsigned int ovfl_mode;
+};
+
+/*
+ * Structure used to setup the RDMA control egress context.
+ */
+struct rdma_ctrlqp_setup {
+ unsigned long long base_addr;
+ unsigned int size;
+};
+#endif /* _CXGB3_OFFLOAD_CTL_DEFS_H */
diff --git a/drivers/net/cxgb3/cxgb3_defs.h b/drivers/net/cxgb3/cxgb3_defs.h
new file mode 100644
index 000..ddaba3f
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_defs.h
@@ -0,0 +1,100 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyri
[PATCH 8/10] cxgb3 - offload capabilities
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the offload capabilities of the
Chelsio network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_offload.c | 1204 +
drivers/net/cxgb3/l2t.c | 558 +
2 files changed, 1762 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_offload.c
b/drivers/net/cxgb3/cxgb3_offload.c
new file mode 100644
index 000..1b963d8
--- /dev/null
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -0,0 +1,1204 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "common.h"
+#include "regs.h"
+#include "cxgb3_ioctl.h"
+#include "cxgb3_ctl_defs.h"
+#include "cxgb3_defs.h"
+#include "l2t.h"
+#include "firmware_exports.h"
+#include "cxgb3_offload.h"
+
+static LIST_HEAD(client_list);
+static LIST_HEAD(ofld_dev_list);
+static DEFINE_MUTEX(cxgb3_db_lock);
+
+static DEFINE_RWLOCK(adapter_list_lock);
+static LIST_HEAD(adapter_list);
+
+static const unsigned int MAX_ATIDS = 64 * 1024;
+static const unsigned int ATID_BASE = 0x10;
+
+static inline int offload_activated(struct t3cdev *tdev)
+{
+ struct adapter *adapter = tdev2adap(tdev);
+
+ return (test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map));
+}
+
+/**
+ * cxgb3_register_client - register an offload client
+ * @client: the client
+ *
+ * Add the client to the client list,
+ * and call backs the client for each activated offload device
+ */
+void cxgb3_register_client(struct cxgb3_client *client)
+{
+ struct t3cdev *tdev;
+
+ mutex_lock(&cxgb3_db_lock);
+ list_add_tail(&client->client_list, &client_list);
+
+ if (client->add) {
+ list_for_each_entry(tdev, &ofld_dev_list, ofld_dev_list) {
+ if (offload_activated(tdev))
+ client->add(tdev);
+ }
+ }
+ mutex_unlock(&cxgb3_db_lock);
+}
+EXPORT_SYMBOL(cxgb3_register_client);
+
+/**
+ * cxgb3_unregister_client - unregister an offload client
+ * @client: the client
+ *
+ * Remove the client to the client list,
+ * and call backs the client for each activated offload device.
+ */
+void cxgb3_unregister_client(struct cxgb3_client *client)
+{
+ struct t3cdev *tdev;
+
+ mutex_lock(&cxgb3_db_lock);
+ list_del(&client->client_list);
+
+ if (client->remove) {
+ list_for_each_entry(tdev, &ofld_dev_list, ofld_dev_list) {
+ if (offload_activated(tdev))
+ client->remove(tdev);
+ }
+ }
+ mutex_unlock(&cxgb3_db_lock);
+}
+EXPORT_SYMBOL(cxgb3_unregister_client);
+
+/**
+ * cxgb3_add_clients - activate register clients for an offload device
+ * @tdev: the offload device
+ *
+ * Call backs all registered clients once a offload device is activated
+ */
+void cxgb3_add_clients(struct t3cdev *tdev)
+{
+ struct cxgb3_client *client;
+
+ mutex_lock(&cxgb3_db_lock);
+ list_for_each_entry(client, &client_list, client_list) {
+ if (client->add)
+ client->add(tdev);
+ }
+ mutex_unlock(&cxgb3_db_lock);
+}
+
+/
[PATCH 9/10] cxgb3 - register definitions
From: Divy Le Ray <[EMAIL PROTECTED]> This patch implements the registers definitions for the Chelsio network adapter's driver. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/regs.h | 2754 ++ 1 files changed, 2754 insertions(+), 0 deletions(-) diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h new file mode 100644 index 000..74c440b --- /dev/null +++ b/drivers/net/cxgb3/regs.h @@ -0,0 +1,2754 @@ +#define A_SG_CONTROL 0x0 + + +#define S_DROPPKT20 +#define V_DROPPKT(x) ((x) << S_DROPPKT) +#define F_DROPPKTV_DROPPKT(1U) + + +#define S_EGRGENCTRL19 +#define V_EGRGENCTRL(x) ((x) << S_EGRGENCTRL) +#define F_EGRGENCTRLV_EGRGENCTRL(1U) + + +#define S_USERSPACESIZE14 +#define M_USERSPACESIZE0x1f +#define V_USERSPACESIZE(x) ((x) << S_USERSPACESIZE) + +#define S_HOSTPAGESIZE11 +#define M_HOSTPAGESIZE0x7 +#define V_HOSTPAGESIZE(x) ((x) << S_HOSTPAGESIZE) + +#define S_FLMODE9 +#define V_FLMODE(x) ((x) << S_FLMODE) +#define F_FLMODEV_FLMODE(1U) + + +#define S_PKTSHIFT6 +#define M_PKTSHIFT0x7 +#define V_PKTSHIFT(x) ((x) << S_PKTSHIFT) + +#define S_ONEINTMULTQ5 +#define V_ONEINTMULTQ(x) ((x) << S_ONEINTMULTQ) +#define F_ONEINTMULTQV_ONEINTMULTQ(1U) + + +#define S_BIGENDIANINGRESS2 +#define V_BIGENDIANINGRESS(x) ((x) << S_BIGENDIANINGRESS) +#define F_BIGENDIANINGRESSV_BIGENDIANINGRESS(1U) + + +#define S_ISCSICOALESCING1 +#define V_ISCSICOALESCING(x) ((x) << S_ISCSICOALESCING) +#define F_ISCSICOALESCINGV_ISCSICOALESCING(1U) + + +#define S_GLOBALENABLE0 +#define V_GLOBALENABLE(x) ((x) << S_GLOBALENABLE) +#define F_GLOBALENABLEV_GLOBALENABLE(1U) + + +#define S_AVOIDCQOVFL24 +#define V_AVOIDCQOVFL(x) ((x) << S_AVOIDCQOVFL) +#define F_AVOIDCQOVFLV_AVOIDCQOVFL(1U) + + +#define S_OPTONEINTMULTQ23 +#define V_OPTONEINTMULTQ(x) ((x) << S_OPTONEINTMULTQ) +#define F_OPTONEINTMULTQV_OPTONEINTMULTQ(1U) + + +#define S_CQCRDTCTRL22 +#define V_CQCRDTCTRL(x) ((x) << S_CQCRDTCTRL) +#define F_CQCRDTCTRLV_CQCRDTCTRL(1U) + + +#define A_SG_KDOORBELL 0x4 + + +#define S_SELEGRCNTX31 +#define V_SELEGRCNTX(x) ((x) << S_SELEGRCNTX) +#define F_SELEGRCNTXV_SELEGRCNTX(1U) + + +#define S_EGRCNTX0 +#define M_EGRCNTX0x +#define V_EGRCNTX(x) ((x) << S_EGRCNTX) + +#define A_SG_GTS 0x8 + + +#define S_RSPQ29 + +#define V_RSPQ(x) ((x) << S_RSPQ) + +#define G_RSPQ(x) (((x) >> S_RSPQ) & M_RSPQ) + + +#define S_NEWTIMER16 +#define M_NEWTIMER0x1fff + +#define V_NEWTIMER(x) ((x) << S_NEWTIMER) + +#define S_NEWINDEX0 +#define M_NEWINDEX0x +#define V_NEWINDEX(x) ((x) << S_NEWINDEX) + +#define A_SG_CONTEXT_CMD 0xc + + +#define S_CONTEXT_CMD_OPCODE28 +#define M_CONTEXT_CMD_OPCODE0xf +#define V_CONTEXT_CMD_OPCODE(x) ((x) << S_CONTEXT_CMD_OPCODE) + +#define S_CONTEXT_CMD_BUSY27 +#define V_CONTEXT_CMD_BUSY(x) ((x) << S_CONTEXT_CMD_BUSY) +#define F_CONTEXT_CMD_BUSYV_CONTEXT_CMD_BUSY(1U) + + +#define S_CQ_CREDIT20 + +#define M_CQ_CREDIT0x7f + +#define V_CQ_CREDIT(x) ((x) << S_CQ_CREDIT) + +#define G_CQ_CREDIT(x) (((x) >> S_CQ_CREDIT) & M_CQ_CREDIT) + + +#define S_CQ19 + +#define V_CQ(x) ((x) << S_CQ) +#define F_CQV_CQ(1U) + +#define F_CQV_CQ(1U) + + +#define S_RESPONSEQ18 +#define V_RESPONSEQ(x) ((x) << S_RESPONSEQ) +#define F_RESPONSEQV_RESPONSEQ(1U) + + +#define S_EGRESS17 +#define V_EGRESS(x) ((x) << S_EGRESS) +#define F_EGRESSV_EGRESS(1U) + + +#define S_FREELIST16 +#define V_FREELIST(x) ((x) << S_FREELIST) +#define F_FREELISTV_FREELIST(1U) + + +#define S_CONTEXT0 +#define M_CONTEXT0x +#define V_CONTEXT(x) ((x) << S_CONTEXT) + +#define G_CONTEXT(x) (((x) >> S_CONTEXT) & M_CONTEXT) + + +#define A_SG_CONTEXT_DATA0 0x10 + + +#define A_SG_CONTEXT_DATA1 0x14 + + +#define A_SG_CONTEXT_DATA2 0x18 + + +#define A_SG_CONTEXT_DATA3 0x1c + + +#define A_SG_CONTEXT_MASK0 0x20 + + +#define A_SG_CONTEXT_MASK1 0x24 + + +#define A_SG_CONTEXT_MASK2 0x28 + + +#define A_SG_CONTEXT_MASK3 0x2c + + +#define A_SG_RSPQ_CREDIT_RETURN 0x30 + + +#define S_CREDITS0 +#define M_CREDITS0x +#define V_CREDITS(x) ((x) << S_CREDITS) + +#define A_SG_DATA_INTR 0x34 + + +#define S_ERRINTR31 +#define V_ERRINTR(x) ((x) << S_ERRINTR) +#define F_ERRINTRV_ERRINTR(1U) + + +#define A_SG_HI_DRB_HI_THRSH 0x38 + + +#define A_SG_HI_DRB_LO_THRSH 0x3c + + +#define A_SG_LO_DRB_HI_THRSH 0x40 + + +#define A_SG_LO_DRB_LO_THRSH 0x44 + + +#define A_SG_RSPQ_FL_STATUS 0x4c + + +#define S_RSPQ0DISABLED8 + +#define A_SG_EGR_RCQ_DRB_THRSH 0x54 + + +#define S_HIRCQDRBTHRSH16 +#define M_HIRCQDRBTHRSH0x7ff +#define V_HIRCQDRBTHRSH(x) ((x) << S_HIRCQDRBTHRSH) + +#define S_LORCQDRBTHRS
[PATCH 10/10] cxgb3 - build files and versioning
From: Divy Le Ray <[EMAIL PROTECTED]> This patch implements build files and versioning for the Chelsio T3 network adapter's driver. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/Kconfig | 18 ++ drivers/net/Makefile|1 + drivers/net/cxgb3/Makefile |8 drivers/net/cxgb3/version.h | 24 4 files changed, 51 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 6e863aa..543374d 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2357,6 +2357,24 @@ config CHELSIO_T1 To compile this driver as a module, choose M here: the module will be called cxgb. +config CHELSIO_T3 +tristate "Chelsio Communications T3 10Gb Ethernet support" +depends on PCI +help + This driver supports Chelsio T3-based gigabit and 10Gb Ethernet + adapters. + + For general information about Chelsio and our products, visit + our website at <http://www.chelsio.com>. + + For customer support, please visit our customer support page at + <http://www.chelsio.com/support.htm>. + + Please send feedback to <[EMAIL PROTECTED]>. + + To compile this driver as a module, choose M here: the module + will be called cxgb3. + config EHEA tristate "eHEA Ethernet support" depends on IBMEBUS diff --git a/drivers/net/Makefile b/drivers/net/Makefile index f270bc4..d316ee0 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_E1000) += e1000/ obj-$(CONFIG_IBM_EMAC) += ibm_emac/ obj-$(CONFIG_IXGB) += ixgb/ obj-$(CONFIG_CHELSIO_T1) += chelsio/ +obj-$(CONFIG_CHELSIO_T3) += cxgb3/ obj-$(CONFIG_EHEA) += ehea/ obj-$(CONFIG_BONDING) += bonding/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o diff --git a/drivers/net/cxgb3/Makefile b/drivers/net/cxgb3/Makefile new file mode 100644 index 000..3434679 --- /dev/null +++ b/drivers/net/cxgb3/Makefile @@ -0,0 +1,8 @@ +# +# Chelsio T3 driver +# + +obj-$(CONFIG_CHELSIO_T3) += cxgb3.o + +cxgb3-objs := cxgb3_main.o ael1002.o vsc8211.o t3_hw.o mc5.o \ + xgmac.o sge.o l2t.o cxgb3_offload.o diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h new file mode 100644 index 000..61de82e --- /dev/null +++ b/drivers/net/cxgb3/version.h @@ -0,0 +1,24 @@ +/* + * * + * File: * + * version.h* + * * + * Description: * + * Chelsio driver version defines. * + * * + * Copyright (c) 2003 - 2006 Chelsio Communications, Inc.* + * All rights reserved. * + * * + * Maintainers: [EMAIL PROTECTED] * + * * + * http://www.chelsio.com* + * * + / +/* $Date: 2006/10/31 18:57:51 $ $RCSfile: version.h,v $ $Revision: 1.3 $ */ +#ifndef __CHELSIO_VERSION_H +#define __CHELSIO_VERSION_H +#define DRV_DESC "Chelsio T3 Network Driver" +#define DRV_NAME "cxgb3" +// Driver version +#define DRV_VERSION "1.0" +#endif //__CHELSIO_VERSION_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/10] cxgb3 - on board memory, MAC and PHY
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements on board memory, MAC and PHY management
for the Chelsio T3 network adapter's driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/ael1002.c | 223 +
drivers/net/cxgb3/mc5.c | 453 +++
drivers/net/cxgb3/vsc8211.c | 208
drivers/net/cxgb3/xgmac.c | 383
4 files changed, 1267 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
new file mode 100644
index 000..761c719
--- /dev/null
+++ b/drivers/net/cxgb3/ael1002.c
@@ -0,0 +1,223 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver.
+ *
+ * Copyright (C) 2005-2006 Chelsio Communications. All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+#include "common.h"
+#include "regs.h"
+
+enum {
+ AEL100X_TX_DISABLE = 9,
+ AEL100X_TX_CONFIG1 = 0xc002,
+ AEL1002_PWR_DOWN_HI = 0xc011,
+ AEL1002_PWR_DOWN_LO = 0xc012,
+ AEL1002_XFI_EQL = 0xc015,
+ AEL1002_LB_EN = 0xc017,
+
+ LASI_CTRL = 0x9002,
+ LASI_STAT = 0x9005
+};
+
+static void ael100x_txon(struct cphy *phy)
+{
+ int tx_on_gpio = phy->addr == 0 ? F_GPIO7_OUT_VAL : F_GPIO2_OUT_VAL;
+
+ msleep(100);
+ t3_set_reg_field(phy->adapter, A_T3DBG_GPIO_EN, 0, tx_on_gpio);
+ msleep(30);
+}
+
+static int ael1002_power_down(struct cphy *phy, int enable)
+{
+ int err;
+
+ err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL100X_TX_DISABLE, !!enable);
+ if (!err)
+ err = t3_mdio_change_bits(phy, MDIO_DEV_PMA_PMD, MII_BMCR,
+ BMCR_PDOWN, enable ? BMCR_PDOWN : 0);
+ return err;
+}
+
+static int ael1002_reset(struct cphy *phy, int wait)
+{
+ int err;
+
+ if ((err = ael1002_power_down(phy, 0)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL100X_TX_CONFIG1, 1)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_PWR_DOWN_HI, 0)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_PWR_DOWN_LO, 0)) ||
+ (err = mdio_write(phy, MDIO_DEV_PMA_PMD, AEL1002_XFI_EQL, 0x18)) ||
+ (err = t3_mdio_change_bits(phy, MDIO_DEV_PMA_PMD, AEL1002_LB_EN,
+ 0, 1 << 5)))
+ return err;
+ return 0;
+}
+
+static int ael1002_intr_noop(struct cphy *phy)
+{
+ return 0;
+}
+
+static int ael100x_get_link_status(struct cphy *phy, int *link_ok,
+ int *speed, int *duplex, int *fc)
+{
+ if (link_ok) {
+ unsigned int status;
+ int err = mdio_read(phy, MDIO_DEV_PMA_PMD, MII_BMSR, &status);
+
+ /*
+* BMSR_LSTATUS is latch-low, so if it is 0 we need to read it
+* once more to get the current link state.
+*/
+ if (!err && !(status & BMSR_LSTATUS))
+ err = mdio_read(phy, MDIO_DEV_PMA_PMD, MII_BMSR,
+ &status);
+ if (err)
+ return err;
+ *link_ok = !!(status & BMSR_LSTATUS);
+ }
+ if (speed)
+ *speed = SPEED_1;
+ if (duplex)
+ *duplex = DUPLEX_FULL;
+ return 0;
+}
+
+static struct cphy_ops ael1002_ops = {
+ .reset = ael1002_reset,
+ .intr_enable = ael1002_intr_noop,
+ .intr_disable= ael1002_intr_noop,
+ .intr_clear = ael1002_intr_noop,
+ .intr_handler= ael1002_intr_noop,
+ .get_link_status = ael100x_get_link_status,
+ .power_down = ael1002_power_down,
+};
+
+void t3_ael1002_phy_prep(struct cphy *phy, adapter_t *adapter, int phy_addr,
+const struct mdio_ops *mdio_ops)
+{
+ cphy_init(phy, adapter, phy_addr, &ael1002_ops, mdio_ops);
+ ael100x_txon(phy);
+}
+
+static int ael1006_reset(struct cphy *phy, int wait)
+{
+ return t3_phy_reset(phy, MDIO_DEV_PMA_PMD, wait);
+}
+
+static int ael1006_intr_enable(struct cphy *phy)
+{
+ return mdio_write(phy, MDIO_DEV_PMA_PMD, LASI_CTRL, 1);
+}
+
+static int ael1006_intr_disable(struct cphy *phy)
+{
+ return mdio_write(phy, MDIO_DEV_PMA_PMD, LASI_CTRL, 0);
+}
+
+static int ael1006_intr_clear(struct cphy *phy)
+{
+ u32 val;
+
+ return mdio_read(phy, MDIO_DEV_PMA_PMD, LASI_STAT, &val);
+}
+
+static int ael1006_intr_handler(struct cphy *phy)
+{
+ unsigned int status;
+ int err = mdio_read(phy, MDI
[PATCH 1/10] cxgb3 - main header files
From: Divy Le Ray <[EMAIL PROTECTED]>
This patch implements the main header files of
the Chelsio T3 network driver.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h | 317 +++
drivers/net/cxgb3/common.h | 702 ++
drivers/net/cxgb3/cxgb3_ioctl.h | 165
drivers/net/cxgb3/firmware_exports.h | 145 +++
4 files changed, 1329 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
new file mode 100644
index 000..318fe6c
--- /dev/null
+++ b/drivers/net/cxgb3/adapter.h
@@ -0,0 +1,317 @@
+/*
+ * This file is part of the Chelsio T3 Ethernet driver for Linux.
+ *
+ * Copyright (C) 2003-2006 Chelsio Communications. All rights reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file included in this
+ * release for licensing terms and conditions.
+ */
+
+/* This file should not be included directly. Include common.h instead. */
+
+#ifndef __T3_ADAPTER_H__
+#define __T3_ADAPTER_H__
+
+#include
+#include
+#include
+#include
+#include
+#include "t3cdev.h"
+#include
+#include
+#include
+
+typedef irqreturn_t (*intr_handler_t)(int, void *);
+
+struct vlan_group;
+
+struct port_info {
+ struct net_device *dev;
+ struct vlan_group *vlan_grp;
+ const struct port_type_info *port_type;
+ u8 rx_csum_offload;
+ u8 nqsets;
+ u8 first_qset;
+ struct cphy phy;
+ struct cmac mac;
+ struct link_config link_config;
+ struct net_device_stats netstats;
+ int activity;
+};
+
+struct work_struct;
+struct dentry;
+
+enum { /* adapter flags */
+ FULL_INIT_DONE = (1 << 0),
+ USING_MSI = (1 << 1),
+ USING_MSIX = (1 << 2),
+};
+
+struct rx_desc;
+struct rx_sw_desc;
+
+struct sge_fl { /* SGE per free-buffer list state */
+ unsigned int buf_size; /* size of each Rx buffer */
+ unsigned int credits; /* # of available Rx buffers */
+ unsigned int size; /* capacity of free list */
+ unsigned int cidx; /* consumer index */
+ unsigned int pidx; /* producer index */
+ unsigned int gen; /* free list generation */
+ struct rx_desc *desc; /* address of HW Rx descriptor ring */
+ struct rx_sw_desc *sdesc; /* address of SW Rx descriptor ring */
+ dma_addr_t phys_addr; /* physical address of HW ring start */
+ unsigned int cntxt_id; /* SGE context id for the free list */
+ unsigned long empty;/* # of times queue ran out of buffers */
+};
+
+/*
+ * Bundle size for grouping offload RX packets for delivery to the stack.
+ * Don't make this too big as we do prefetch on each packet in a bundle.
+ */
+# define RX_BUNDLE_SIZE 8
+
+struct rsp_desc;
+
+struct sge_rspq { /* state for an SGE response queue */
+ unsigned int credits; /* # of pending response credits */
+ unsigned int size; /* capacity of response queue */
+ unsigned int cidx; /* consumer index */
+ unsigned int gen; /* current generation bit */
+ unsigned int polling; /* is the queue serviced through NAPI? */
+ unsigned int holdoff_tmr; /* interrupt holdoff timer in 100ns */
+ unsigned int next_holdoff; /* holdoff time for next interrupt */
+ struct rsp_desc *desc; /* address of HW response ring */
+ dma_addr_t phys_addr; /* physical address of the ring */
+ unsigned int cntxt_id; /* SGE context id for the response q */
+ spinlock_t lock; /* guards response processing */
+ struct sk_buff *rx_head;/* offload packet receive queue head */
+ struct sk_buff *rx_tail;/* offload packet receive queue tail */
+
+ unsigned long offload_pkts;
+ unsigned long offload_bundles;
+ unsigned long eth_pkts; /* # of ethernet packets */
+ unsigned long pure_rsps;/* # of pure (non-data) responses */
+ unsigned long imm_data; /* responses with immediate data */
+ unsigned long rx_drops; /* # of packets dropped due to no mem */
+ unsigned long async_notif; /* # of asynchronous notification events */
+ unsigned long empty;/* # of times queue ran out of credits */
+ unsigned long nomem;/* # of responses deferred due to no mem */
+ unsigned long unhandled_irqs; /* # of spurious intrs */
+};
+
+struct tx_desc;
+struct tx_sw_desc;
+
+struct sge_txq {/* state for an SGE Tx queue */
+ unsigned long flags;/* HW DMA fetch status */
+
Re: FW: [Fwd: Re: [PATCH scsi-misc 2/2] megaraid_sas: LSI Logic MegaR AID SAS RA ID D river]
On Wed, Aug 31, 2005 at 08:34:07PM -0400, Bagalkote, Sreenivas wrote: > > - the ->queuecommand cleanup patch I sent you a awhile ago doesn't > >seem to be applied > > I seem to have missed it. I will submit the patch after inclusion ok, this is really just a small cleanup anyway. > > - there's quite a lot of slightly odd formating, it would be nice > >if you could run the code through scripts/Lindent. > > I ran Lindent. It looks worse :( I am submitting the Lindent output anyway. > > > > > If you could sent out an unmangled patch (even as attachment or on > > LSI's ftp side) I'd like to take another, closer look. > > I am sending this from a Linux box. Hopefully, this will comeout clean. > Sorry for mangled patches. It's still wrapped, unfortunately. Let's retry as an attachment. Anyway, I think we can put the patch in now. I have a few more really small things that I'd like to address, I will submit patches as soon as I have a codebase that I can create patches against. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Question] [Patch] How get instruction pointer of user space ???
Hi:
Thanks to Yingchao Zhou and Gaurav Dhiman first, for your answers.
I get it now! but it look we must update knownledge about this.
I read copy_thread() in arch/i386/kernel/process.c, the code piece of
this function are:
/* childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long)
p->thread_info)) - 1;
** /*
* The below -8 is to reserve 8 bytes on top of the ring0 stack.
* This is necessary to guarantee that the entire "struct pt_regs"
* is accessable even if the CPU haven't stored the SS/ESP registers
* on the stack (interrupt gate does not save these registers
* when switching to the same priv ring).
* Therefore beware: accessing the xss/esp fields of the
* "struct pt_regs" is possible, but they may contain the
* completely wrong values.
*/
childregs = (struct pt_regs *) ((unsigned long) childregs - 8);
*childregs = *regs;
*/
Oh, clear all secrets on it now! that comment is very readable.
OK, see my code to do experiement in do_fork() :
/*
static void
my_check_regs_with_offset(struct pt_regs *orig_regs)
{
struct thread_info *thread_info;
struct pt_regs *pt_regs;
unsigned long *stack_bottom;
thread_info = current_thread_info();
pt_regs = (struct pt_regs*)((unsigned long)thread_info+THREAD_SIZE-8);
pt_regs--;
stack_bottom = 8+(unsigned long)(pt_regs+1),
printk("\tbottom=%p, pt_regs = %p eip=%p\n",
stack_bottom,
pt_regs,
pt_regs->eip);
}
static void
my_check_regs_without_offset(struct pt_regs *orig_regs)
{
struct thread_info *thread_info;
struct pt_regs *pt_regs;
unsigned long *stack_bottom;
thread_info = current_thread_info();
pt_regs = (struct pt_regs*)((unsigned long)thread_info+THREAD_SIZE);
pt_regs--;
stack_bottom = (unsigned long)(pt_regs+1),
printk("\tbottom=%p, pt_regs = %p eip=%p\n",
stack_bottom,
pt_regs,
pt_regs->eip);
}*/
in do_fork() function, I insert code:
/* if (current->tgid && (current->tgid % 10 == 0) && get_task_mm(current)) {
unsigned long stack_bottom;
struct thread_info *thread_info;
struct mm_struct *mm;
printk("withOUT offset: ");
my_check_regs_without_offset(regs);
printk("with offset: ");
my_check_regs_with_offset(regs);
printk("sizeof(struct pt_regs) = %d THREAD_SIZE=%x ",
sizeof(struct pt_regs),
THREAD_SIZE);
thread_info = current_thread_info();
printk("thread_info=%p\n", thread_info);
printk("In kernel words:");
printk(" KSTK_TOP(task)=%x\n", KSTK_TOP(current));
printk(" task_pt_regs(task)=%x\n", task_pt_regs(current));
printk(" KSTK_EIP(task)=%x\n", KSTK_EIP(current));
printk("In fact:\n");
stack_bottom = 8+(unsigned long)(regs+1);
printk(" bottom=%p, pt_regs=%p, eip=%p\n",stack_bottom,regs,regs->eip);
mm = get_task_mm(current);
printk(" code address range: [%x-%x]\n", mm->start_code, mm->end_code);
printk("\n");
}
*/
the printk() output:
*withOUT offset: bottom=dac16000, pt_regs = dac15fc4 eip=0282
with offset: bottom=dac16000, pt_regs = dac15fbc eip=0012d402
sizeof(struct pt_regs) = 60 THREAD_SIZE=2000 thread_info=dac14000
In kernel words: KSTK_TOP(task)=deebb020
task_pt_regs(task)=dac15fc4
KSTK_EIP(task)=282
In fact:
bottom=dac16000, pt_regs=dac15fbc, eip=0012d402
code address range: [8047000-80d1b80]
withOUT offset: bottom=dac16000, pt_regs = dac15fc4 eip=0282
with offset: bottom=dac16000, pt_regs = dac15fbc eip=00c1f402
sizeof(struct pt_regs) = 60 THREAD_SIZE=2000 thread_info=dac14000
In kernel words: KSTK_TOP(task)=deebb020
task_pt_regs(task)=dac15fc4
KSTK_EIP(task)=282
In fact:
bottom=dac16000, pt_regs=dac15fbc, eip=00c1f402
code address range: [8047000-80d1b80]
withOUT offset: bottom=dac16000, pt_regs = dac15fc4 eip=0282
with offset: bottom=dac16000, pt_regs = dac15fbc eip=00c1f402
sizeof(struct pt_regs) = 60 THREAD_SIZE=2000 thread_info=dac14000
In kernel words: KSTK_TOP(task)=deebb020
task_pt_regs(task)=dac15fc4
KSTK_EIP(task)=282
In fact:
bottom=dac16000, pt_regs=dac15fbc, eip=00c1f402
code address range: [8047000-80d1b80]
* It's look there have one anonymous hero update copy_thread(), but
he/she forget to update
macro task_pt_regs(task). After browse LXR, I found 2.6.11 have not this
change yet.
the copy_thread() in 2.6.12.3 and 2.6.13 include this "dummy" offset, at
least.
the attachment is a patch for that.
Is right my words?
thanks again.
sailor
--- linux-2.6.13/include/asm-i386/processor.h.orig 2005-09-01 11:19:22.0 +0800
+++ linux-2.6.13/include/asm-i386/processor.h 2005-09-01 11:26:04.0 +0800
@@ -538,11 +538,13 @@
unsigned long *__ptr = (unsigned long *)(info); \
(unsigned long)(&__ptr[THREAD_SIZE_LONGS]); \
})
-
+/*
+ * subtract 8 here, to skip dummy offset, see copy_thread() for detailed comment.
+ */
#define task_pt_regs(task) \
({ \
struct pt_regs *__regs__; \
- __regs__ = (struct pt_regs *)KSTK_TOP((task)->thread_info); \
+ __regs__ = (struct pt_regs *)(K
Re: How linear address translate to physical address in kernel space?
and back with __va. These are used to communicate with devices usually, which are also mapped to some location. But these only work when the mapping is direct as show above. When highmem support is on, you can't get to memory that is not mapped in. But there's no need to use __pa or __va to get to memory just for itself. Usually they are used when dealing with devices that have DMA or some other need to find a physical address. If a device needs to write to memory (usually only knowing about the physical location of the memory) you get that memory with GFP_DMA flag, which guarantees that you will get memory that is mapped directly. -- 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: I have one doubt about detail of page reclaim.
[EMAIL PROTECTED] wrote: I am reading code of function balabce_pgdat(pg_data_t *pgdat, int nr_pages, int order). Sorry, that have one typo, it should be balance_pgdat(). liyu/NOW:D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: Re: PATCH for ide_floppy
yes, #define IDEFLOPPY_TICKS_DELAY HZ/20 seems to be the solution. when I've tested some values for IDEFLOPPY_TICKS_DELAY in December 2004, I cannot found the best value for this. The Kernel version was 2.6.8 from the SuSE9.2 distribution. I take a look in ide-cd.c and found there the function cdrom_timer_expiry as a possibility to handle timeout issues smoother. I tried this function as idefloppy_timer_expiry in ide-floppy.c in combination with IDEFLOPPY_TICKS_DELAY 60 as a best result for all cases. It seems to reach out to change IDEFLOPPY_TICKS_DELAY as suggested from you, idefloppy_timer_expiry is not really necessary. -Original Message- Date: Fri, 1 Jul 2005 19:08:58 +0200 Subject: Re: Re: PATCH for ide_floppy From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> On 7/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > it's not really a performance issue but more a timeout issue. > 'IDEFLOPPY_TICKS_DELAY 60' avoids error messages in /var/log/messages > like 'reset ide ...'. > Without the idefloppy_timer_expiry the data transfer to the ide-floppy > is pending a long time between some transfer of data. The floppy LED > indicated this too. > With kernel 2.4.x I've never had this problem. This seems related to 2.4 -> 2.6 HZ change. > > @@ -317,7 +324,13 @@ > > unsigned long flags; > > } idefloppy_floppy_t; > > > > +#if 0 > > #define IDEFLOPPY_TICKS_DELAY 3 /* default delay for ZIP 100 > */ > > +#define IDEFLOPPY_TICKS_DELAY 6 /* default delay for ZIP 100 > > --ms 2005/01/01 */ > > +#define IDEFLOPPY_TICKS_DELAY 12 /* default delay for ZIP 100 > > --ms 2005/01/01 */ > > +#endif > > +#define IDEFLOPPY_TICKS_DELAY 60 /* default delay for ZIP 100 > > --ms 2005/01/07 */ > > + "ticks" delay should be expressed using HZ #define IDEFLOPPY_TICKS_DELAY HZ/20 for 50msec delay (N.B. the comment in the code about default delay being 50msec also seems wrong - it was more like ~33msec in 2.4) Could you please test if this fixes your problems? Bartlomiej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
Andy Isaacson <[EMAIL PROTECTED]> wrote: > On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote: >> I don't know if VM_REGISTERED is a good idea or not, but it should be >> absolutely impossible for the kernel to reclaim "registered" (aka pinned) >> memory, no matter what. For RDMA services (such as Infiniband, iWARP, etc), >> it's normal for non-root processes to pin hundreds of megabytes of memory, >> and that memory better be locked to those physical pages until the >> application deregisters them. > > If you take the hardline position that "the app is the only thing that > matters", your code is unlikely to get merged. Linux is a > general-purpose OS. All userspace hardware drivers with DMA will require pinned pages (and some of them will require continuous memory). Since this memory may be scheduled to be accessed by DMA, reclaiming those pages may (aka. will) result in "random" memory corruption unless done by the driver itself. You can't even set a time limit, the driver may have allocated all DMA memory to queued transfers, and some media needs to get plugged in by the lazy robot. As soon as the robot arrives - boom. (For the same reason, this memory MUST NOT be freed if the application terminates abnormally, e.g. killed by OOM). In other words, you need to make this memory as unaccessible as the framebuffer on a graphic card. If that causes a lockup, you better had prevented that while allocating. > In a Linux context, I doubt that fullblown SA is necessary or > appropriate. Rather, I'd suggest two new signals, SIGMEMLOW and > SIGMEMCRIT. The userland comms library registers handlers for both. > When the kernel decides that it needs to reclaim some memory from the > app, it sends SIGMEMLOW. The comms library then has the responsibility > to un-reserve some memory in an orderly fashion. If a reasonable [1] > time has expired since SIGMEMLOW and the kernel is still hungry, the > kernel sends SIGMEMCRIT. At this point, the comms lib *must* unregister > some memory [2] even if it has to drop state to do so; if it returns > from the signal handler without having unregistered the memory, the > kernel will SIGKILL. Choosing Data loss vs. finitely stalled system may sometimes be a bad decision. If I designes an application that might get a "gimme memory or die", I'd reserve an extra bunch of memory with the only purpose of being released in this situation. If the kernel had done that instead, this part of memory could have been used e.g. as a read-only disk cache in the meantime (off cause provided somebody cared to implement that). > [2] Is there a way for the kernel to pass down to userspace how many > pages it wants, maybe in the sigcontext? Then you'd need only one signal. I think this interface is usefull, it would e.g. allow a picture viewer to cache as many decoded and scaled pictures as the RAM permits, freeing them if the RAM gets full and the swap would have to be used. -- "When the pin is pulled, Mr. Grenade is not our friend. -U.S. Marine Corps - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
Ed L Cashin <[EMAIL PROTECTED]> wrote: > +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 > + When the aoe driver is a module, use Is there any reason for this inconsistent behaviour? > + /sys/module/aoe/parameters/aoe_iflist instead of ^^^ Why does the module name need to be part of the attribute? That's redundant. That's redundant. > + There is a boot option for the built-in aoe driver and a > + corresponding module parameter, aoe_iflist. Without this option, > + all network interfaces may be used for ATA over Ethernet. Here is a > + usage example for the module parameter. > + > +modprobe aoe_iflist="eth1 eth3" ^ "aoe" -- Top 100 things you don't want the sysadmin to say: 63. Oracle will be down until 8pm, but you can come back in and finish your work when it comes up tonight. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] FUSE permission modell (Was: fuse review bits)
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it's "..", then the application can step out of the chroot using clone(2).
>
> Note: using chdir in a vfsmount outside of your namespace works, however
> you won't be able to walk off that vfsmount (to its parent or children).
IMO the '..' file descriptor should be attached to it's chroot domain.
This should avoid all chroot-escapes, even with fd-passing etc.
I wonder why nobody thought of that. Either it's too obvious or too stupid.
--
Funny quotes:
7. You have the right to remain silent. Anything you say will be misquoted,
then used against you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel page table and module text
Allison <[EMAIL PROTECTED]> wrote: > I want to find where each module is loaded in memory by traversing the > module list . Once I have the address and the size of the module, I > want to read the bytes in memory of the module and hash it to check > it's integrity. JFTR: This may work against random memory corruption, but it will fail for detecting attacks. -- Top 100 things you don't want the sysadmin to say: 54. Uh huh.."nu -k $USER".. no problemsure thing... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 libata-dev-2.6] sata_via: VT6420 PATA support - please help, correct this driver's alfa source code
I traid to write VT6420 PATA support into the libata: sata_via.c,
because the way through via82cxxx.c doesn't work.
Please help me with this and correct this driver's alfa source code.
/* */ ... this sign in source code means, that this part i added into
current libata-dev-2.6: sata_via.c
Petr Novák
[EMAIL PROTECTED]
/*
sata_via.c - VIA Serial ATA controllers
Maintained by: Jeff Garzik <[EMAIL PROTECTED]>
Please ALWAYS copy linux-ide@vger.kernel.org
on emails.
Copyright 2003-2004 Red Hat, Inc. All rights reserved.
Copyright 2003-2004 Jeff Garzik
The contents of this file are subject to the Open
Software License version 1.1 that can be found at
http://www.opensource.org/licenses/osl-1.1.txt and is included herein
by reference.
Alternatively, the contents of this file may be used under the terms
of the GNU General Public License version 2 (the "GPL") as distributed
in the kernel source COPYING file, in which case the provisions of
the GPL are applicable instead of the above. If you wish to allow
the use of your version of this file only under the terms of the
GPL and not to allow others to use your version of this file under
the OSL, indicate your decision by deleting the provisions above and
replace them with the notice and other provisions required by the GPL.
If you do not delete the provisions above, a recipient may use your
version of this file under either the OSL or the GPL.
--
To-do list:
* VT6420 PATA support
* VT6421 PATA support
*/
#include
#include
#include
#include
#include
#include
#include "scsi.h"
#include
#include
#include
#define DRV_NAME"sata_via"
#define DRV_VERSION "1.2" /* */
enum board_ids_enum {
vt6420,
vt6420pata, /* */
vt6421,
};
enum {
SATA_CHAN_ENAB = 0x40, /* SATA channel enable */
SATA_INT_GATE = 0x41, /* SATA interrupt gating */
SATA_NATIVE_MODE= 0x42, /* Native mode enable */
SATA_PATA_SHARING = 0x49, /* PATA/SATA sharing func ctrl */
VT_CTLSTAT = 0x60, /* IDE control and status (per
port) */ /* */
PORT0 = (1 << 1),
PORT1 = (1 << 0),
ALL_PORTS = PORT0 | PORT1,
N_PORTS = 2,
NATIVE_MODE_ALL = (1 << 7) | (1 << 6) | (1 << 5) | (1 << 4),
SATA_EXT_PHY= (1 << 6), /* 0==use PATA, 1==ext phy */
SATA_2DEV = (1 << 5), /* SATA is master/slave */
};
static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id
*ent);
static u32 svia_scr_read (struct ata_port *ap, unsigned int sc_reg);
static void svia_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
/* */
static void vt6420pata_phy_reset(struct ata_port *ap);
static void vt6420pata_cbl_detect(struct ata_port *ap);
static struct pci_device_id svia_pci_tbl[] = {
{ 0x1106, 0x3149, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6420 },
{ 0x1106, 0x4149, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6420pata }, /* */
{ 0x1106, 0x3249, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6421 },
{ } /* terminate list */
};
static struct pci_driver svia_pci_driver = {
.name = DRV_NAME,
.id_table = svia_pci_tbl,
.probe = svia_init_one,
.remove = ata_pci_remove_one,
};
static Scsi_Host_Template svia_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
.ioctl = ata_scsi_ioctl,
.queuecommand = ata_scsi_queuecmd,
.eh_strategy_handler= ata_scsi_error,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
.sg_tablesize = LIBATA_MAX_PRD,
.max_sectors= ATA_MAX_SECTORS,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
.use_clustering = ATA_SHT_USE_CLUSTERING,
.proc_name = DRV_NAME,
.dma_boundary = ATA_DMA_BOUNDARY,
.slave_configure= ata_scsi_slave_config,
.bios_param = ata_std_bios_param,
};
static struct ata_port_operations svia_sata_ops = {
.port_disable = ata_port_disable,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
.check_status = ata_check_status,
.exec_command
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe <[EMAIL PROTECTED]> wrote: > systr_pmem_read() and systr_pmem_write() just calls ptrace > PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target > process whenever patch modules is loading You'll have to do that anyway, since you'll need to atomically store two machine words. At least you'll have to lock access to the corresponding memory page(s). -- Error, no keyboard -- press F1 to continue. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> >> 1) Only allow mount over a directory for which the user has write >> access (and is not sticky) >> >> 2) Use nosuid,nodev mount options [...] > Do these solve all the security concerns with unprivileged mounts, or > are there other barriers/concerns? Should there be ulimit (or rlimit) > style restrictions on how many mounts/binds a user is allowed to have > to prevent users from abusing mount privs? Definitively. Mountpoints use kernel space, the users could DoS the machine. The per-Machine-limit isn't fine-grained enough, since the users may DoS each other. You'll have to avoid users capturing system daemons in D state or in slowed-down artificial directory-forests, too. I think namespaces will do most the trick. > I was thinking about this a while back and thought having a user-mount > permissions file might be the right way to address lots of these > issues. Essentially it would contain information about what > users/groups were allowed to mount what sources to what destinations > and with what mandatory options. Users being able to mount random fs containing suid or device nodes are root whenever they want to. If you want to mount with dev or suid, use sudo and restrict the mount to a limited set of images/devices/whatever. -- Anger, fear, aggression. The Dark Side of the Force are they. Once you start down the Dark Path, forever will it dominate your destiny. -- Jedi Master Yoda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Coredump when program run as root?
Ralf Hildebrandt <[EMAIL PROTECTED]> wrote: > Most UNIX variants disable core dumps in programs that have changed their > uid or euid during operation. This includes Solaris and Linux. > > Well, squid does exactly that. How can I still get a coredump? I really > need one. Kernel 2.6.11.7 It cannot change the (e)uid if it is run as user. Maybe this helps. -- Top 100 things you don't want the sysadmin to say: 78. Do you smell something? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SATA] status reports updated
Bodo Eggert <[EMAIL PROTECTED]> wrote: > Tomasz Chmielewski <[EMAIL PROTECTED]> wrote: >> Is there a way to check what firmware a drive has > > The obvious one: hdparm Or, since hdparm doesn't work for SCSI devices, cat /sys/block/sd$n/device/rev (might depend on the vendor) -- Funny quotes: 21. Support bacteria - they're the only culture some people have. Friß, Spammer: [EMAIL PROTECTED] [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: intercepting syscalls
Richard B. Johnson <[EMAIL PROTECTED]> wrote: > LD_PRELOAD some custom 'C' runtime library functions, grab open() > read(), write(), etc. This will work wonderfully with static binaries. -- "Bravery is being the only one who knows you're afraid." -David Hackworth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SATA] status reports updated
Tomasz Chmielewski <[EMAIL PROTECTED]> wrote: > Is there a way to check what firmware a drive has The obvious one: hdparm -- "Just because you are paranoid, do'nt mean they're not after you." -- K.Cobain Friß, Spammer: [EMAIL PROTECTED] [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: encrypted swap (was Re: [PATCH encrypted swsusp 1/3] core functionality)
Andy Isaacson <[EMAIL PROTECTED]> wrote: > * the key is automatically regenerated every 2 hours (or whatever); as >pages encrypted under the old key age out, it can be freed eventually Changing the key would not help, since if you can get the swap pages on a running system, you can also get the keys, and if you are using a limited set of keys (you obviously want that), using more than one key will just add a small linear factor to cracking the whole swap data of an offline system. -- Field experience is something you don't get until just after you need it. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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: [Crosspost] GNU/Linux userland?
John Lenz wrote: On 04/13/05 14:40:31, Oliver Korpilla wrote: You might also look at www.openembedded.org It has support for cross compiling, and with one command can build an entire userland. Not sure if it is exactly a fit for what you want to do, but it seems very close. Thanks, this sounds great, and together with the directions I got about Gentoo and Heretix/Rubyx seems to precisely match my request. Thanks to you, and thanks to all helpful replies! :) With kind regards, Oliver Korpilla - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sound/oss/rme96xx.c: fix two check after use
Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Apr 13, 2005 at 04:17:42AM +0200, Adrian Bunk wrote: >> This patch fixes two check after use found by the Coverity checker. > > Bullshit. ->private_data is set by rme96xx_open() to guaranteed non-NULL > and never changed elsewhere. Same comment about reading the fscking > source, BUG_ON(), etc. If there are checks, they should be there for a purpose, and any sane reader will asume these checks to be nescensary. If they are dead code, you can say that, but please don't flame Adrian for fixing obviously buggy code in a way that is sane and at least more correct than the original without using several days of his lifetime to analyze the whole driver. Instead, you could provide the correct fix. -- Funny quotes: 33. If lawyers are disbarred and clergymen defrocked, doesn't it follow that electricians can be delighted, musicians denoted, cowboys deranged, models deposed, tree surgeons debarked, and dry cleaners depressed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Digi Neo 8: linux-2.6.12_r2 jsm driver
Kilau, Scott <[EMAIL PROTECTED]> wrote: > However, neither IBM nor Digi wants this thread's patch to be applied, > and yet Christoph wants to do it, completely out of spite, to break our > out-of-tree open source driver. > > This is the problem that I have. I think you should supply a patch that makes the in-kernel driver print a short notice about your other driver. E.g. The foo driver is a stripped-down version of the bar driver. To get the additional configuration and diagnosis infrastructure, see the instructions on url. -- Top 100 things you don't want the sysadmin to say: 49. What's this switch for anyways...? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [INFO] Kernel strict versioning
Franco "Sensei" <[EMAIL PROTECTED]> wrote: > Krzysztof Halasa wrote: >> It isn't enough. The same compiler and the same .config - yes. But that >> means you'd have no progress within, say, 2.6. Only bug fixes. >> There _is_ a tree like that - 2.6.11.Xs are only bugfixes. > > Ok, this adds a new information. Let me explain what I understand now. > > When a new component is added to the kernel, let's say support for a new > file system, a .config entry is created (CONFIG_MYFS=y|m). Why is this > entry breaking compatibility? I mean, symbols still remains the same. > The addition of symbols is not a breaking point. A kernel feature may require a different (bigger, slower, ...) internal data structure, which isn't desired unless you use that feature. Or it will change the semantics of some functions, e.g. functions being a noop (and optimized away) for uniprocessor with no highmem will do some important task on a SMP machine with 4 GB. >> Asking for one modules dir only is similar to asking for only one >> /boot/vmlinuz-2.6 kernel file. > > Quite the same, yes. You can still have different kernels of course! By > the way, another stupid curiosity is why /lib/modules instead of /boot? Boot vs. bootloader. The same reason that allows lilo.conf to be in /etc See http://www.pathname.com/fhs/ , too -- Top 100 things you don't want the sysadmin to say: 81. The drive ate the tape but that's OK, I brought my screwdriver. Friß, Spammer: [EMAIL PROTECTED] [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: snd-ens1371 (alsa) & joystick woes
Patrick McFarland <[EMAIL PROTECTED]> wrote: > Speaking of which... is there anyone out > there with a ens1371 that actually works right with joysticks? Yes, I'm using the oss driver. -- Airstrikes always overshoot the target, artillery always falls short. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz <[EMAIL PROTECTED]> wrote: >>Copyright law only _explicitly_ grants a monopoly on preparation of >>derivative works. However, it is trivial, and overwhelmingly common, >>for a copyright owner to grant a license to create a derivative work >>that is conditional on how the licensee agrees to distribute (or not >>distribute) the derivative work. > > This would, of course, only make sense if you *had* to agree to the license > to *create* the derivative work. If you were able to create the derivative > work under first sale or fair use rights, then the restrictions in the > contract would not apply to you. If you buy a W*nd*ws install CD, you can create a derived work, e.g. an image of your installation, under the fair use rights (IANAL). Can you distribute that image freely? -- Friendly fire isn't. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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: [RFC] FUSE permission modell (Was: fuse review bits)
Jamie Lokier <[EMAIL PROTECTED]> wrote: > Miklos Szeredi wrote: >> 4) Access should not be further restricted for the owner of the >> mount, even if permission bits, uid or gid would suggest >> otherwise > > Why? Surely you want to prevent writing to files which don't have the > writable bit set? A filesystem may also create append-only files - > and all users including the mount owner should be bound by that. That will depend on the situation. If the user is mounting a tgz owned by himself, FUSE should default to being a convenient hex-editor. >> 5) As much of the available information should be exported via the >> filesystem as possible > > This is the root of the conflict. You are trying to overload the > permission bits and uid/gid to mean something different than they > normally do. > > While it's convenient to see some "remote" information such as the > uid/gid in a tar file, are you sure it's a good idea to break the unix > permissions model - which will break some programs? (For example, try > editing a file with the broken semantics in an editor which checks the > uid/gid of the file against the current user). The editor will try to keep the original permissions, and saving will be less effective. >> 1) Only allow mount over a directory for which the user has write >> access (and is not sticky) > > Seems good - but why not sticky? Mounting a user filesystem in > /tmp/user-xxx/my-mount-point seems not unreasonable - provided the > administrator can delete the directory (which is possible with > detachable mount points). I once mounted a filesystem in ~/tmp after forgetting about it being a symlink to /tmp/$me/tmp, and I had to promise never to do that again. Ng zvqavtug, gur pyrnahc-grzc-fpevcg xvpxrq va. >> 5) The filesystem daemon is free to fill in all file attributes to >> any (sane) value, and the kernel won't modify these. > > Dangerous, because an administrative program might actually trust the > attributes to mean what they normally mean in the unix permissions model. The same risk applies to smbmounted file systems. Sane daemons will do no check besides matching the owner of a file in the user's home against the expected UID and checking the permission mask, since you can't trust users not to mess with files in directories they own. The "best" they can do should be shoothing their own feet. (If the user doesn't own the directory, FUSE shouldn't mount.) -- Top 100 things you don't want the sysadmin to say: 80. I cleaned up the root partition and now there's LOTS of free space. Friß, Spammer:[EMAIL PROTECTED]@whitedoc.info - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic - not syncing: Fatal exception in interupt
The machine crashed again twice today. I have vga=791 so i caugh a bit more of the crash. i enabled serial redirection in the bios so i'm hoping to catch the full dump next time. The first screen shot is with the old resolution so didnt catch much more here... http://www.unix-scripts.com/shaun/host1-2005-04-12-01.png But this screen shot got a nice chunk and looks a bit diffrent. http://www.unix-scripts.com/shaun/host1-2005-04-12-02.png Still looks like there is alot more that i'm missing but by glancing at that dump, to me it definitly seams like bridging is causing this. I'm going to post this to the ebtables lists tomarrow also. Best Regards, Shaun R. - Original Message - From: "Zwane Mwaikambo" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Cc: Sent: Thursday, April 07, 2005 1:09 AM Subject: Re: kernel panic - not syncing: Fatal exception in interupt > On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote: > > > No, sorry, i have to run with bridging support other wise the guests(UML's) > > wont be able to communicate with the outside world. > > Ok in that case, can you connect a serial console so that you can capture > the entire output? > > Thanks, > Zwane > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic - not syncing: Fatal exception in interupt
The last time i crashed i changed the console resolution, i'm hoping it will give me the whole dump this time. I will see if i can get a serial console on it. Best Regards, Shaun Reitan Account Specialist www.NDCHost.com www.cPlicensing.net - Original Message - From: "Zwane Mwaikambo" <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Cc: Sent: Thursday, April 07, 2005 1:09 AM Subject: Re: kernel panic - not syncing: Fatal exception in interupt > On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote: > > > No, sorry, i have to run with bridging support other wise the guests(UML's) > > wont be able to communicate with the outside world. > > Ok in that case, can you connect a serial console so that you can capture > the entire output? > > Thanks, > Zwane > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic - not syncing: Fatal exception in interupt
No, sorry, i have to run with bridging support other wise the guests(UML's) wont be able to communicate with the outside world. Best Regards, Shaun R - Original Message - From: "Zwane Mwaikambo" <[EMAIL PROTECTED]> To: "shaun" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, April 06, 2005 1:10 AM Subject: Re: kernel panic - not syncing: Fatal exception in interupt > On Tue, 5 Apr 2005, shaun wrote: > > > +Hardware Specs > > Dual Xeon 800FSB > > Intel Server Board > > 4GB ECC DDR > > 3ware 9500 Sata Raid Card > > 5x200 GB sata drives in a raid 10 Config (1 hot spare) > > Dual Nic > > > > +OS Specs > > CentOS 3.4 running a custom 2.6.x kernel patched with UML SKA's Patch > > eth0 is 0.0.0.0 promisc and assigned to a bridge (br0) > > tuntap devices up > > ebtables is enabled and loaded with rules > > Is it possible to run without the bridge for testing purposes, and be > sure to put the normal networking load? > > > My problem is that every other week or so the machine crashes. It never > > dumps the error to the logs so all i have is a screen shot of the console. > > I have put some serious stress on this machine and have been unable to > > duplicate the problem (running 20 guest UML's half running va-ctcs and the > > other half compiling a 2.6 kernel). Below is a link to 2 screen shots i > > have (about 2 weeks apart). I started off using a 2.6.10 kernel when the > > problem started. Last time the machine crashed i built a 2.6.11.5 kernel > > and disabled APM and ACPI in the kernel config. Any body know whats going > > on here. > > > > http://www.unix-scripts.com/shaun/host-screenshot-1.png > > http://www.unix-scripts.com/shaun/host-screenshot-2.png > > > > Kernel Config... http://www.unix-scripts.com/shaun/2.6.11.5-hr1_.config > > > > -- > > Best Regards, > > > > Shaun Reitan > > > > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ChangeLog-2.4.30
These files missing too: http://www.kernel.org/pub/linux/kernel/v2.4/patch-2.4.30.bz2 http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.30.tar.bz2 Petr Novák, [EMAIL PROTECTED] Christophe Lucas napsal(a): Is this normal ;-) ChangeLog-2.4.30 is not found on www.kernel.org ? http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.30 Have a nice day, ~Christophe PS: Please CC me :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SATA] libata-dev queue updated
Jeff Garzik napsal(a): Merged recent upstream changes into libata-dev queue. No new patches have found their way into libata-dev since last email. BK URL, Patch URL, and changelog attached. Note that the patch is diff'd against 2.6.11-bk6, which won't exist until four hours after this email is sent. Jeff It is hard to add support for VIA VT6420 PATA channel (SATA works fine)? Does anybody working on it? I can help with beta testing this driver. (The way through via82cxxx.c don't working.) Is it possible add to To-do list to sata_via.c or add this support to driver? sata_via.c: ---cut here--- To-do list: * VT6420 PATA support <= new line * VT6421 PATA support */ ---cut here--- Petr Novák, [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/
linux-kernel-announce@vger.kernel.org Your application has been approved Thu, 24 Mar 2005 11:28:16 -0800
Hello, We sent you an email a while ago, because you now qualify for a much lower rate based on the biggest rate drop in years. You can now get $327,000 for as little as $617 a month! Bad credit? Doesn't matter, ^low rates are fixed no matter what! Follow this link to process your application and a 24 hour approval: http://www.lbaloan.net/?id=c77 Best Regards, Preston Duvall http://www.lbaloan.net/byebye.php - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Pre-approved Application for linux-kernel-announce@vger.kernel.org Thu, 17 Mar 2005 15:45:41 -0800
Hello, We sent you an email a while ago, because you now qualify for a much lower rate based on the biggest rate drop in years. You can now get $327,000 for as little as $617 a month! Bad credit? Doesn't matter, low rates are fixed no matter what! Follow this link to process your application and a 24 hour approval: http://www.alowerrate.net/?id=c77 Best Regards, Augustus Felton http://www.alowerrate.net/byebye.php - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][SPARC64][kernel 2.4] __show_regs() calls to printk()
Hello, in the file arch/sparc64/kernel/process.c, the function __show_regs() prints the content of the registers four by four, but every register's content needs 16 caracters to be printed; the name of the register needs 4 caracters; and one caracter is needed to separate this value from the next register's name. Therefore, it uses 84 caracters per line, but the VT100 has only 80, so we are using two lines instead of only one, shortening the content of the (eventual) Oops one could sent. I think we could perform better, by suppressing the space between the name of the register and it's value. By this way, instead of writing : g4: f800 g5: 0004 g6: f80001348000 g7: we would have : g4:f800 g5:0004 g6:f80001348000 g7: It remains fully understandable, I think. Alternately, we could print only 3 registers per line, but since the registers are grouped 8 by 8, it would be less logical. This would also have a sense for Sparc32 computers, and, in the same file, for the functions show_stackframe and show_regwindow. Any comments? Should I make a patch? -- Emmanuel Colbus Club GNU/Linux ENSIMAG - Departement Telecoms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CRASH] kernel 2.4.27 on sparc64 SMP (Ultrasparc I)
Hello, We had yesterday a crash of our Linux sparc server. Here is the machine's uname -a : Linux ensilinx6 2.4.27 #2 SMP dim nov 14 18:58:56 CET 2004 sparc64 GNU/Linux Here is the content of the screen I found today : 0 i1: i2: 0001 i3: 00767b20 i4: f80003eeffd8 i5: 0001 i6: f80003eef741 i7: 0042ea5c CPU[4]: local_irq_count[0] irqs_running[0] TSTATE: 009980009601 TPC: 00418424 TNPC: 00418428 Y: b8c8 Not tainted g0: g1: g2: 00708900 g3: 0070B700 g4: f800 g5: 0004 g6: f80001348000 g7: o0: o1: 0032 o2: f80052b17e58 o3: 0004 o4: f80052b17d80 o5: 0001 SP: f8000134b681 ret_pc: 00418460 l0: 00708700 l1: 00767a38 l2: 0004 l3: 0065a800 l4: 0001 l5: l6: 000f l7: f8000134bfd0 i0: i1: i2: 0001 i3: 00767b20 i4: f8000134bfd8 i5: 0001 i6: f8000134b741 i7: 0042ea5c And here is the message I found in /var/log/messages (note that it differs from the screen's content ) : Mar 9 05:49:34 ensilinx6 kernel: __alloc_pages: 1-order allocation failed (gfp= 0x20/0) Mar 9 05:49:34 ensilinx6 kernel: \|/ \|/ Mar 9 05:49:34 ensilinx6 kernel: "@'/ .. \`@" Mar 9 05:49:34 ensilinx6 kernel: /_| \__/ |_\ Mar 9 05:49:34 ensilinx6 kernel: \__U_/ Mar 9 05:49:35 ensilinx6 kernel: swapper(0): Kernel bad sw trap 5 Mar 9 05:49:35 ensilinx6 kernel: CPU[0]: local_irq_count[0] irqs_running[0] Mar 9 05:49:35 ensilinx6 kernel: TSTATE: 004480009600 TPC: 0046a350 TNPC: 0046a354 Y: Not tainted Mar 9 05:49:35 ensilinx6 kernel: g0: 00713800 g1: 0065f758 g2: 0001 g3: 0008b924 Mar 9 05:49:35 ensilinx6 kernel: g4: f800 g5: f80003ef4000 g6: 00414000 g7: Mar 9 05:49:35 ensilinx6 kernel: o0: 0039 o1: 00715c00 o2: 0020 o3: Mar 9 05:49:35 ensilinx6 kernel: o4: o5: 00715e29 sp: 00416a31 ret_pc: 0046a348 Mar 9 05:49:35 ensilinx6 kernel: l0: 00661d80 l1: 0001 l2: l3: 0002 Mar 9 05:49:35 ensilinx6 kernel: l4: l5: 0020 l6: 00661848 l7: f8000135c600 Mar 9 05:49:35 ensilinx6 kernel: i0: i1: 0001 i2: 00661d70 i3: f80052b0d400 Mar 9 05:49:36 ensilinx6 kernel: i4: i5: 005b5160 i6: 00416b01 i7: 0046a398 Mar 9 05:49:36 ensilinx6 kernel: Caller[0046a398] Mar 9 05:49:36 ensilinx6 kernel: Caller[00466388] Mar 9 05:49:36 ensilinx6 kernel: Caller[00466ad4] Mar 9 05:49:36 ensilinx6 kernel: Caller[0059bb50] Mar 9 05:49:36 ensilinx6 kernel: Caller[02035600] Mar 9 05:49:36 ensilinx6 kernel: Caller[02034280] Mar 9 05:49:36 ensilinx6 kernel: Caller[005a9ec0] Mar 9 05:49:36 ensilinx6 kernel: Caller[005aa37c] Mar 9 05:49:36 ensilinx6 kernel: Caller[005a0bc8] Mar 9 05:49:36 ensilinx6 kernel: Caller[005a0d64] Mar 9 05:49:36 ensilinx6 kernel: Caller[005a0f40] Mar 9 05:49:36 ensilinx6 kernel: Caller[0044f628] Mar 9 05:49:36 ensilinx6 kernel: Caller[0040ef40] Mar 9 05:49:36 ensilinx6 kernel: Caller[00418460] Mar 9 05:49:36 ensilinx6 kernel: Caller[0069677c] Mar 9 05:49:36 ensilinx6 kernel: Caller[00404678] Mar 9 05:49:36 ensilinx6 kernel: Caller[] Mar 9 05:49:36 ensilinx6 kernel: Instruction DUMP: 92100011 7fff8126 94100015 <91d02005> 1067 ab356000 7fff7129 94102001 106fff73 No idea what can have happened. There was nobody on the server at this time. Has anybody any idea about this crash? -- Emmanuel Colbus Club GNU/Linux ENSIMAG - Departement Telecoms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Application approval for linux-kernel-announce@vger.kernel.org Wed, 09 Mar 2005 03:45:56 -0800
Hello, We sent you an email a while ago, because you now qualify for a much lower rate based on the biggest rate drop in years. You can now get $327,000 for as little as $617 a month! Bad credit? Doesn't matter, low rates are fixed no matter what! Follow this link to process your application and a 24 hour approval: http://www.qklenders.com/x/loan.php?id=d17 Best Regards, Earnest Hoffman http://www.qklenders.com/x/st.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Application approval for kernel@vger.kernel.org Mon, 07 Mar 2005 09:37:14 -0800
Hello, We sent you an email a while ago, because you now qualify for a much lower rate based on the biggest rate drop in years. You can now get $327,000 for as little as $617 a month! Bad credit? Doesn't matter, low rates are fixed no matter what! Follow this link to process your application and a 24 hour approval: http://www.qklenders.com/x/loan.php?id=d17 Best Regards, Margie Johnston http://www.qklenders.com/x/st.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Error message during boot: module ide-detect not found
Hello, when booting a 2.6 kernel of a Debian distribution (Sarge) I always get the above error message. Additionally, the ide chipset is not detected and hard disc and ide - cdrom drives are not available. In '/etc/modules' , 'ide-detect' is listed. When I change this to 'ide-generic', everything is fine. This might be a problem of Debian distribution ( Sarge ) or more general ?? /RalfS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with GPM / loading kernel module during boot
Hello, I found a problem since I started to use the 2.6 kernel release. I use the console mouse tool gpm. It is started the usual way with a script '/etc/init.d/gpm' and symbolic links in the runlevel directories '/etc/rcX.d" . When I installed gpm ( Debian Distribution ) I wondered that gpm was not active after booting. I had to call '/etc/init.d/gpm start' after login as root to make it working. I started to look at the problem after login and everything else seemed to be ok, even lsmod showed the neccessary modules - psmouse ... - in this case for gpm. I stopped gpm ( gpm -k ) , unloded the psmouse ... and restarted gpm again. Not working but psmouse was loaded again. So I thought that the request to the kernel to load the modules corresponding to '/dev/psaux' took too long for gpm to come up. To validate this, I made an entry 'psmouse' into the file '/etc/modules' - the list of modules that are loaded during boot. This solved the problem. QUESTION:: Is this a special problem for thegpm program or a general problem for all programs/drivers that are trying to access a device node and forcing the kernel to load the approciate module(s)? /RalfS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Application approval for linux-kernel-announce@vger.kernel.org Sat, 05 Mar 2005 11:57:15 -0800
Hello, We sent you an email a while ago, because you now qualify for a much lower rate based on the biggest rate drop in years. You can now get $325,000 for as little as $615 a month! Bad credit? Doesn't matter, low rates are fixed no matter what! Follow this link to process your application and a 24 hour approval: http://www.gr8lendez.com/x/loan.php?id=d17 Best Regards, Dan Magee http://www.gr8lendez.com/x/st.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: via 6420 pata/sata controller
I downloaded new kernel 2.6.11, applied your's via82cxxx.c patch and
compiled it (.config was derived "make oldconfig" from 2.6.8 kernel from
Debian Sarge 3.1).
I created initrd.img with this settings:
/etc/mkinitrd/mkinitrd.conf
--- cut here ---
MODULES=dep
--- cut here ---
/etc/mkinitrd/modules
###
jbd
ext3
ide-core
via82cxxx
I boot PC with this settings:
/etc/modules
###
ide-cd
via82cxxx
Results:
Everything is the same, dmesg, lspci, lspci -n, cat /proc/ioports, lsmod
as the last email.
Controller still don't working :'(.
PS: I don't add anything into pci_ids.h, I only applied your's
via82cxxx.c patch:
#define PCI_DEVICE_ID_VIA_6420 0x4149
Your's Sincerely
Petr Novák
[EMAIL PROTECTED]
Jeff Garzik napsal(a):
If I had to guess, I would try the attached patch. The via82cxxx.c
driver is a bit annoying in that, here we do not talk to the ISA
bridge but to the PCI device 0x4149 itself.
If this doesn't work, I could probably whip together a quick PATA
driver for libata that works on this hardware.
Jeff
= drivers/ide/pci/via82cxxx.c 1.27 vs edited =
--- 1.27/drivers/ide/pci/via82cxxx.c2005-02-03 02:24:29 -05:00
+++ edited/drivers/ide/pci/via82cxxx.c 2005-03-02 01:28:26 -05:00
@@ -79,6 +79,7 @@
u8 rev_max;
u16 flags;
} via_isa_bridges[] = {
+ { "vt6420", 0x4149, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8235", PCI_DEVICE_ID_VIA_8235, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8233a", PCI_DEVICE_ID_VIA_8233A,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
@@ -635,9 +636,10 @@
}
static struct pci_device_id via_pci_tbl[] = {
- { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
- { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
- { 0, },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C576_1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_VIA, 0x4149) },
+ { },/* terminate list */
};
MODULE_DEVICE_TABLE(pci, via_pci_tbl);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sched_yield behavior
First of all, thanks to all for the helpful replies. I have simplified my example, because I was only interested in understanding if there was particular behavior performed by the new scheduler after a sched_yield() call. Anyway, I try to explain better my requirements. I have to implement a task which splits its job into two different blocks: the first concerns operations which must be performed within a limited time interval, so a very fast response is required; the second one concerns operations which can be a little delayed without problems. For some other reasons, the two blocks cannot be implemented in two different tasks. Therefore, because of the presence of the real-time block, an high real-time priority must be assigned to the whole task. On the other hand, if it uses the resources for a long time interval, it should sched_yield on behalf of other tasks (of course only after the real-time block operations have been completed). Giovanni -- Initial Header --- >From : [EMAIL PROTECTED] To : "Giovanni Tusa" [EMAIL PROTECTED] Cc : linux-kernel@vger.kernel.org Date : Sun, 27 Feb 2005 12:02:13 -0500 Subject : Re: sched_yield behavior > On Sun, 2005-02-27 at 11:58 +0100, Giovanni Tusa wrote: > > Hi all, > > I have a question about the sched_yield behavior of Linux O(1) scheduler, > > for RT tasks. > > By reading some documentation, I found that " real-time tasks are a > > special case, because > > when they want to explicitly yield the processor to other waiting processes, > > they are merely > > moved to the end of their priority list (and not inserted into the expired > > array, like conventional > > processes)." > > I have to implement an RT task with the highest priority in the system (it > > is also the only task within the > > priority list for such priority level). Moreover, it has to be a SCHED_FIFO > > task, so that it can preempt > > SCHED_RR ones, because of its strong real-time requirements. However, > > sometimes it should relinquish the > > CPU, to give to other tasks a chance to run. > > Now, what happen if it gives up the CPU by means of the sched_yield() system > > call? > > If I am not wrong, the scheduler will choose it again (it will be still the > > higher priority task, and the only of its priority list). > > I have to add an explicit sleep to effectively relinquish the CPU for some > > time, or the scheduler can deal with such a > > situation in another way? > > What exactly are you trying to do? I don't understand how the task > could have "strong real-time requirements" if it's CPU bound. What is > the exact nature of the real time constraint? > > 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/ > ________ 6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero! Scaricalo su INTERNET GRATIS 6X http://www.libero.it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/2] drivers/char/vt.c: remove unnecessary code
On Mon, 28 Feb 2005, Stelian Pop wrote:
> On Mon, Feb 28, 2005 at 04:06:14PM +0100, [EMAIL PROTECTED] wrote:
>
> > + /* Setting par[]'s elems at 0. */
> > + memset(par, 0, NPAR*sizeof(unsigned int));
>
> No need for the comment here, everybody understands C.
I knew this code would be understood, but I like comments :-) .
Well, without it, it gives :
--- old/drivers/char/vt.c 2004-12-24 22:35:25.0 +0100
+++ new/drivers/char/vt.c 2005-02-28 18:19:11.782717810 +0100
@@ -1655,8 +1655,8 @@
vc_state = ESnormal;
return;
case ESsquare:
- for(npar = 0 ; npar < NPAR ; npar++)
- par[npar] = 0;
+ memset(par, 0, NPAR*sizeof(unsigned int));
npar = 0;
vc_state = ESgetpars;
if (c == '[') { /* Function key */
Any other comments/remarks, or is _this_ patch version acceptable?
--
Emmanuel Colbus
Club GNU/Linux
ENSIMAG - Departement telecoms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: via 6420 pata/sata controller
>>Bartlomiej Zolnierkiewicz wrote:
>>> On Tuesday 30 of March 2004 15:24, Zdenek Tlusty wrote:
>>>
>>>>Hello,
>>>>
>>>>I have problem with via 6420 controller under linux (I have
mandrake 9.1
>>>>with kernel 2.4.25 with libata patch version 16).
>>>>This controller has two sata and one pata channels. Sata channel
works fine
>>>>with libata. My problem is with pata channel. I have pata hard disk
on this
>>>>controller. Bios of the controller detected this disk but linux did
not.
>>>>What is the current status of the driver for this controller?
>>>>Thank you for your time.
>>>
>>>
>>> There are some patches floating around adding support for VT6410
>>> (not VT6420) to generic IDE PCI driver. This controller may also work
>>> with generic IDE PCI driver (PCI VendorID/ProductID needs to be added
>>> to drivers/ide/pci/generic.h and drivers/ide/pci/generic.c).
>>
>>VT 6420 should be added to via82cxxx.c, since it does the necessary bus
>>setup and such. AFAICS it is programmed just like all the other VIA
>>PATA controllers.
>>
>> BTW Does anybody has contacts in VIA?
>>
>>Sure... I'll check my VT 6420 cards as well. It should just be another
>>PCI id added to via82cxxx.c.
>>
>> Jeff
>>
>
>Hello,
>
>I tried to modify via82cxxx.c and .h, but was unsuccessful. Has anyone
got it to work properly?
>
>Kamil Okac
* Per my message (last quoted line), the user should add the PCI ID to
* drivers/ide/via82cxxx.[ch] and see what happens.
*
* Jeff
Hello,
i trying resurrect this discussion again for solve this problem successfuly.
My experiments:
I changed two files:
usr/src/linux-2.6.11-rc5/include/linux/pci_ids.h
--- cut here ---
#define PCI_DEVICE_ID_VIA_8703_51_0 0x3148
#define PCI_DEVICE_ID_VIA_8237_SATA 0x3149
#define PCI_DEVICE_ID_VIA_6420 0x4149; <= this i was
add
#define PCI_DEVICE_ID_VIA_XN266 0x3156
#define PCI_DEVICE_ID_VIA_8754C_0 0x3168
--- cut here ---
/use/src/linux-2.6.11-rc5/drivers/ide/pci/via82cxxx.c
--- cut here ---
{ "vt8233c", PCI_DEVICE_ID_VIA_8233C_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8233", PCI_DEVICE_ID_VIA_8233_0, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt8231", PCI_DEVICE_ID_VIA_8231, 0x00, 0x2f, VIA_UDMA_100 },
{ "vt6420", PCI_DEVICE_ID_VIA_6420, 0x00, 0x2f, VIA_UDMA_100 },
; <= this i was add
{ "vt82c686b", PCI_DEVICE_ID_VIA_82C686, 0x40, 0x4f, VIA_UDMA_100 },
{ "vt82c686a", PCI_DEVICE_ID_VIA_82C686, 0x10, 0x2f, VIA_UDMA_66 },
--- cut here ---
But i was not successful :'-(
Informations from my computer:
dmesg
--- cut here ---
Linux version 2.6.11-rc5 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002
(Debian prerelease)) #1 Sat Feb 26 02:18:02 CET 2005
.
.
.
SCSI subsystem initialized
libata version 1.10 loaded.
sata_via version 1.1
sata_via(:00:0f.0): routed to hard irq line 10
ata1: SATA max UDMA/133 cmd 0x6200 ctl 0x6302 bmdma 0x6600 irq 10
ata2: SATA max UDMA/133 cmd 0x6400 ctl 0x6502 bmdma 0x6608 irq 10
ata1: no device found (phy stat )
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
--- cut here ---
lspci
--- cut here ---
:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA
RAID Controller (rev 50)
:00:0f.1 RAID bus controller: VIA Technologies, Inc.: Unknown device
4149 (rev 80)
--- cut here ---
lspci -n
--- cut here ---
:00:0f.0 0104: 1106:3149 (rev 50)
:00:0f.1 0104: 1106:4149 (rev 80)
--- cut here ---
cat /proc/ioports
--- cut here ---
6200-6207 : :00:0f.0
6200-6207 : sata_via
6300-6303 : :00:0f.0
6300-6303 : sata_via
6400-6407 : :00:0f.0
6400-6407 : sata_via
6500-6503 : :00:0f.0
6500-6503 : sata_via
6600-660f : :00:0f.0
6600-660f : sata_via
6700-67ff : :00:0f.0
6700-67ff : sata_via
6800-6807 : :00:0f.1
6900-6903 : :00:0f.1
6a00-6a07 : :00:0f.1
6b00-6b03 : :00:0f.1
6c00-6c0f : :00:0f.1
--- cut here ---
This controller talking about:
http://www.sunsway.com.hk/products/sata-ide.html
http://www.viatech.co.jp/en/Products/vt6420.jsp
http://www.via.com.tw/en/products/peripherals/serial-ata_raid/vt6420/
Forum where they talked about - linux talking:
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1565.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1814.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1821.html
_http://www.ussg.iu.edu/hypermail/linux/kernel/0404.2/0573.html_
Forum where they talked about - freebsd talking:
http://lists.freebsd.org/pipermail/freebsd-current/2004-January/017706.html
http://lists.freebsd.org/pipermail/freebsd-current/2004-January/017725.html
Your's Sincerely
Petr Novák
[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/
linux-kernel-announce@vger.kernel.org Your Application Confirmation Fri, 25 Feb 2005 22:17:57 -0800
Hi, Did you know? You can now get $347,000 for as little as $607 a month! Why should you pay more when you can save thousands re-financing at our low rates? Remember, that rates are due to jump withint he next few months. Bad credit? Doesn't matter, low rates are fixed no matter what! Use the extra for home additions, improvements, or whatever you could not afford to do before. Fill out this 30 sec. form and be approved within the next 24 hours. http://www.123ratezz.com/x/loan.php?id=a17 Best Regards, Quincy Washburn http://www.123ratezz.com/x/st.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HCF PCI - suspend
when i return my computer from suspend mode , The HCF pci modem can not work . ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
