Re: udev regression? lsusb silent (no output) since 2.6.22-rc2 at least
On Sat, May 26, 2007 at 10:18:54PM +0200, bert hubert wrote:
> Greg, Kay, kernel people,
>
> Today I booted 2.6.22-rc2 on Ubunty Edgy Eft, and lsusb died on me:
>
> [EMAIL PROTECTED]:~$ lsusb
> [EMAIL PROTECTED]:~$ sudo lsusb
> [EMAIL PROTECTED]:~$
>
> This behaviour persists in rc4. This might be udev related. I'm running:
> ii udev 093-0ubuntu18.0edgy2
>
> USB does work fine.
>
> Bit from strace:
>
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 4 entries */, 4096)= 112
> close(3)= 0
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 4 entries */, 4096)= 112
> getdents64(3, /* 0 entries */, 4096)= 0
> close(3)= 0
> (end of program)
>
> [EMAIL PROTECTED]:~$ ls -l /dev/bus/usb -d
> drwxr-xr-x 3 root root 80 2007-05-26 21:58 /dev/bus/usb
>
> [EMAIL PROTECTED]:~$ ls -l /dev/bus/usb/
> total 0
> lrwxrwxrwx 1 root root 14 2007-05-26 21:58 devices -> .usbfs/devices
>
> [EMAIL PROTECTED]:~$ ls -l /dev/bus/usb/devices
> lrwxrwxrwx 1 root root 14 2007-05-26 21:58 /dev/bus/usb/devices ->
> .usbfs/devices
>
> [EMAIL PROTECTED]:~$ wc -l /dev/bus/usb/devices
> 95 /dev/bus/usb/devices
>
> On another machine (debian etch), with an older kernel, where lsusb does
> work:
What is that kernel version?
This works fine for me here too...
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 26, 2007, at 22:37:02, [EMAIL PROTECTED] wrote: On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said: On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. That's a circular argument, and a fairly trivial one at that. If you can't properly manage your labels, then how do you expect any security at all? Unfortunately, it's not at all as simple as all that. Toshiharu is quite correct that it isn't always easy to actually implement. Consider how many ad-croc usages of 'restorecon' are needed to get a Fedora SELinux box through rc.sysinit: While I don't think restorecon is really necessary to properly boot SELinux-enabled (I've got a Debian box with some heavily customized policy which does so just fine), I am of the opinion that adding a "name" parameter to the file/directory create actions would be useful. For example, with such support you could actually specify a type-transition rule conditional on a specific name or substring: named_type_transition sshd_t tmp_t:sock_file prefix "ssh-" ssh_sock_t; Useful options for matching would be "prefix", "suffix", "substr (start,len)". "regex" would be nice but is sorta computationally intensive and would be likely to cause more problems than it solves. /sbin/restorecon -R /dev 2>/dev/null [ -n "$SELINUX_STATE" ] && restorecon /dev/mapper /dev/mapper/ control >/dev/null 2>&1 These can go away if you modify your policy and pass "-o fscontext=system_u:object_r:dev_t" to the mount command for the /dev tmpfs, changing both the filesystem and the default directory labels from the default "system_u:object_r:tmpfs_t". This will work as long as your policy files contain appropriate transitions from the dev_t type. REBOOTFLAG=`restorecon -v /sbin/init` restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/ resolv.conf >/dev/null 2>&1 [ -n "$SELINUX_STATE" ] && restorecon /tmp [ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1 I believe these are to handle rebooting from non-SELinux mode. There are two solutions to this kind of problem: (1) Failing the boot if the labels are wrong (2) Fixing the labels (and rebooting if necessary) It would appear that FC does the latter, although for certain high- security systems (such as firewalls handling classified/confidential data), the first option is the only acceptable one. [ -n "$SELINUX_STATE" ] && restorecon /dev/pts >/dev/null 2>&1 I think this can be handled with some combination of appropriate SELinux policy and mount options. At least, I don't need this in the boot scripts on my heavily customized Debian SELinux box. [ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path" I don't know what the point of this generic line is; but I certainly don't have anything of the sort on my test system, and it appears to work just fine. And that's just getting the system up to single-user. Things like sendmail and sshd require more restorecon handholding in their rc.init files. Or just look at the creeping horror that is 'restorecond' (in particular, consider that the default restorcond.conf contains the strings '~/public_html' and '~/.mozilla/plugins/ libflashplayer.so'. Yee. Frikkin. Hah. ;) Part of the reason that Fedora has a large quantity of that restorecon and restorecond crap is that there is a certain amount of broken binary software needing executable stack/heap (such as flashplayer), programs without comprehensive or complete policies, or programs which by definition need extra support for SELinux. For example, to really complete the SELinux model you need editors and tools which understand security labels the same way they understand UNIX permissions. With a bit of vim scripting I can probably make it run external commands to read file labels before it reads the file itself and modify /proc/self/attr/fscreate before writing out the file, similar to the way it would keep track of the standard DAC permissions on files it modifies. There's also the fact that corporate products have fixed release schedules so remaining bugs in each release tend to get papered over instead of fixed properly (such as the restorecon in FC init- scripts). I haven't seen many problems with the SELinux model which aren't associated with working around buggy software or missing features. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: input_polldev won't load as a module
Hi Cédric, On Saturday 26 May 2007 17:25, Cédric Augonnet wrote: > Hi, > > When trying to load input_polldev compiled as a module on my > 2.6.22-rc2-mm1 kernel, it is impossible because of some symbols that > are said to be missing : > > [EMAIL PROTECTED]:~$ sudo modprobe input_polldev > FATAL: Error inserting input_polldev > (/lib/modules/2.6.22-rc2-mm1=porcinet/kernel/drivers/input/misc/input-polldev.ko): > Unknown symbol in module, or unknown parameter (see dmesg) > [EMAIL PROTECTED]:~$ dmesg > [ 137.559553] input_polldev: Unknown symbol queue_delayed_work > [ 137.559621] input_polldev: Unknown symbol destroy_workqueue > [ 137.559652] input_polldev: Unknown symbol __create_workqueue > > I enclosed my .config in case it may help. > > On the other hand, if I choose CONFIG_INPUT_POLLDEV=y, it seems to > work without any problem. Provided the Kconfig file, it looks like > this could compiled either like that or as a module. > > Unfortunately, given my very limited understanding i could really not > figure out why these symbols cannot be resolved, so i'll be really > interrested if anyone can propose a solution or an explanation. > It is caused by nyssing GPL license for the module. Please try 2.6.22-rc3, the issue should be fixed by commit 36bd52a49b790a71f3d353cdddf2f22e1e6f84ff. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 3
On 5/26/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: Hi Bret, On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote: > > [ 237.556167] LZO compress successful: orig_size=17448, comp_size=8183 > [ 253.320760] LZO decompress successful: decomp_size=17448 > > 2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input > 2e6c96b687274b629308b29835cebd3af989e0c7 output > > ppc however seems bust > the computer is a g4 mini > Can you please test the 'take 4' version on ppc? Just one line change: Please replace call to lzo1x_decompress_safe() to lzo1x_decompress() in compress-test module. Thanks, Nitin results from take 4 dmesg: [ 1944.508280] LZO compress successful: orig_size=17448, comp_size=8183 [ 1952.098677] LZO decompress successful: decomp_size=17448 [EMAIL PROTECTED]:~# sha1sum /home/bret/test-input output 2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input 2221c586e3eb869af7f4333d4f56b441b9aa8414 output If you need more testing let me know - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add Marvell 6141 PATA support to AHCI driver
Here is a patch against 2.6.22-rc3 that adds support for both the PATA
and SATA portions of the Marvell AHCI-like chip.
The architecture for PATA is quite nice, mimicing AHCI very closely.
Basic port scanning, interrupt handling, freezing and thawing is the
same, and uses the same register offets.
This is completely untested code. But it looks like it should work :)
Engineering questions I need to bounce back to Marvell:
* do I need to worry about PIO/UDMA timing? I don't see any registers
or other knobs dealing with timing. Maybe the controller snoops?
* it appears that I don't have to worry about device selection, that
the controller will handle this for me. But I want to make sure.
* figure out controller commands. these are poorly documented.
controller commands are how one directly accesses the PATA device's
command and control registers, and are necessary to do things like
SRST. Currently the driver only does hard reset.
This is checked into the 'mv-ahci-pata' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
drivers/ata/ahci.c | 496 +++-
include/linux/ata.h |1
2 files changed, 453 insertions(+), 44 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 7baeaff..5bbca8f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -81,6 +81,7 @@ enum {
board_ahci_vt8251 = 2,
board_ahci_ign_iferr= 3,
board_ahci_sb600= 4,
+ board_ahci_mv = 5,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -171,6 +172,7 @@ enum {
AHCI_FLAG_HONOR_PI = (1 << 26), /* honor PORTS_IMPL */
AHCI_FLAG_IGN_SERR_INTERNAL = (1 << 27), /* ignore SERR_INTERNAL */
AHCI_FLAG_32BIT_ONLY= (1 << 28), /* force 32bit */
+ AHCI_FLAG_MV_PATA = (1 << 29), /* PATA port */
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
@@ -178,6 +180,46 @@ enum {
ATA_FLAG_ACPI_SATA,
};
+enum mvp_specific_registers {
+ MVP_D0_TF0 = 0x20, /* dev0 taskfile part 1 */
+ MVP_D0_TF1 = 0x24, /* dev0 taskfile part 2 */
+ MVP_D0_TF2 = 0x28, /* dev0 taskfile part 3 */
+ MVP_D1_TF0 = 0x2C, /* dev1 taskfile part 1 */
+ MVP_D1_TF1 = 0x30, /* dev1 taskfile part 2 */
+ MVP_D1_TF2 = 0x3C, /* dev1 taskfile part 3 */
+};
+
+enum mvp_specific_bits {
+ /* PORT_CMD register */
+ MVP_CMD_HW_RST = (1 << 3), /* Generate H_RESET_N to
+* attached devices.
+* Self de-asserting.
+*/
+
+ /* PORT_IRQ_[STAT,MASK] registers */
+ MVP_IRQ_D0_INTRQ= (1 << 0), /* dev0 INTRQ line */
+ MVP_IRQ_D0_ERR = (1 << 1), /* ERR in dev0 Status reg */
+ MVP_IRQ_D1_INTRQ= (1 << 2), /* dev1 INTRQ line */
+ MVP_IRQ_D1_ERR = (1 << 3), /* ERR in dev1 Status reg */
+ MVP_IRQ_FREEZE = 0,
+ MVP_IRQ_ERROR = MVP_IRQ_FREEZE |
+ MVP_IRQ_D0_ERR | MVP_IRQ_D1_ERR,
+ DEF_MVP_IRQ = MVP_IRQ_ERROR |
+ MVP_IRQ_D0_INTRQ | MVP_IRQ_D1_INTRQ,
+
+ MVP_CMD_DEV1= (1 << 15),/* dev0 == 0, dev1 == 1 */
+ MVP_CMD_ATAPI_RST = (1 << 14),/* cmd==ATA_CMD_DEV_RESET */
+ MVP_CMD_EDD = (1 << 13),/* cmd==ATA_CMD_EDD */
+ MVP_CMD_LBA48 = (1 << 12),/* is an LBA48 cmd */
+ MVP_CMD_PIO_SECT= (1 << 11),/* PIO single/mult sector cmd */
+ MVP_CMD_NODATA = (1 << 10),/* is a non-data cmd */
+ MVP_CMD_READ= (1 << 9), /* data-in (dev->host) */
+ MVP_CMD_DMA = (1 << 8), /* ATA or ATAPI DMA */
+ MVP_CMD_ATAPI = (1 << 7), /* is a PACKET cmd */
+ MVP_CMD_TCQ = (1 << 6), /* is a legacy TCQ cmd */
+ MVP_CMD_CONTROLLER = (1 << 5), /* PATA controller command */
+};
+
struct ahci_cmd_hdr {
u32 opts;
u32 status;
@@ -211,6 +253,8 @@ struct ahci_port_priv {
unsigned intncq_saw_d2h:1;
unsigned intncq_saw_dmas:1;
unsigned intncq_saw_sdb:1;
+
+ int mvp_selected;
};
static u32 ahci_scr_read (struct ata_port *ap, unsigned int sc_reg);
@@ -228,13 +272,22 @@ static void ahci_thaw(struct ata_port *ap);
static void ahci_error_handler(struct ata_port *ap);
Re: sysfs permitions on class leds
On Fri, May 25, 2007 at 03:37:46PM -0300, Rodrigo Pereira wrote: > (sorry my English) > > I'm helping M?rton N?meth in a experimental mail led driver > leds-clevo-mail.c for clevo laptops and I have problems with this > driver: > this files > /sys/class/trigger, /sys/class//dalay_on and > /sys/class//delay_off are created as 644 permissions. Also > ROOT controls the led. I think write udev rules but my rules don't > change this permissions. > > The clevo mail led is a trigger led (time-trigger) for blinks the led > when a new mail arrives. > > How can I change the permissions of the sysfs objects in runtime or > userspace? Just do a 'chmod' on the sysfs file. If you have the proper permissions to do that, it will stick for as long as the sysfs file stays around. hope this helps, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v14
Ingo Molnar wrote: i'm pleased to announce release -v14 of the CFS scheduler patchset. The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ I tried this on 2.6.21.1, Good work! I have a doubt when read this patch: in update_stats_enqueue(), It seem that these statements in two brances of "if (p->load_weight > NICE_0_LOAD)" are same, is it on purpose? Good luck - Li Yu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.21.1] resume doesn't run suspended kernel?
Bill Davidsen wrote: I was testing susp2disk in 2.6.21.1 under FC6, to support reliable computing environment (RCE) needs. The idea is that if power fails, after some short time on UPS the system does susp2disk with a time set, and boots back every so often to see if power is stable. No, I don't want susp2mem until I debug it, console come up in useless mode, console as kalidescope is not what I need. Anyway, I pulled the plug on the UPS, and the system shut down. But when it powered up, it booted the default kernel rather than the test kernel, decided that it couldn't resume, and then did a cold boot. I can bypass this by making the debug kernel the default, but WHY? Is the kernel not saved such that any kernel can be rolled back into memory and run? Actually, the answer is HELL NO, so I really ask if this is the intended mode of operation, that only the default boot kernel will restore. Fedora scripts for hibernation are supposed to tell GRUB to set the default kernel on the next boot to be the current one before suspending to disk, so that it comes up with the same version it was running and the resume can succeed. If the way you're triggering the suspend bypasses this mechanism, you'll see this problem. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udev regression? lsusb silent (no output) since 2.6.22-rc2 at least
On Sat, 2007-05-26 at 22:18 +0200, bert hubert wrote:
> Today I booted 2.6.22-rc2 on Ubunty Edgy Eft, and lsusb died on me:
>
> [EMAIL PROTECTED]:~$ lsusb
> [EMAIL PROTECTED]:~$ sudo lsusb
> [EMAIL PROTECTED]:~$
>
> This behaviour persists in rc4. This might be udev related. I'm running:
> ii udev 093-0ubuntu18.0edgy2
>
> USB does work fine.
>
> Bit from strace:
>
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 4 entries */, 4096)= 112
> close(3)= 0
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 4 entries */, 4096)= 112
> getdents64(3, /* 0 entries */, 4096)= 0
> close(3)= 0
> (end of program)
>
> [EMAIL PROTECTED]:~$ ls -l /dev/bus/usb -d
> drwxr-xr-x 3 root root 80 2007-05-26 21:58 /dev/bus/usb
>
> [EMAIL PROTECTED]:~$ ls -l /dev/bus/usb/
> total 0
> lrwxrwxrwx 1 root root 14 2007-05-26 21:58 devices -> .usbfs/devices
>
> [EMAIL PROTECTED]:~$ ls -l /dev/bus/usb/devices
> lrwxrwxrwx 1 root root 14 2007-05-26 21:58 /dev/bus/usb/devices ->
> .usbfs/devices
>
> [EMAIL PROTECTED]:~$ wc -l /dev/bus/usb/devices
> 95 /dev/bus/usb/devices
>
> On another machine (debian etch), with an older kernel, where lsusb does
> work:
>
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 4 entries */, 4096)= 96
> close(3)= 0
> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 4 entries */, 4096)= 96
> getdents64(3, /* 0 entries */, 4096)= 0
> close(3)= 0
> open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 3 entries */, 4096)= 72
> open("/dev/bus/usb/001/001", O_RDWR)= -1 EACCES (Permission denied)
> open("/dev/bus/usb/001/001", O_RDONLY) = 4
>
> Any clues? Please let me know how I can help solve this problem!
It works fine for me here. Do you have CONFIG_USB_DEVICE_CLASS=y set?
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said: > On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: > > (1) Object labeling has a assumption that labels are always > > properly defined and maintained. This can not be easily achieved. > > That's a circular argument, and a fairly trivial one at that. If you > can't properly manage your labels, then how do you expect any > security at all? Unfortunately, it's not at all as simple as all that. Toshiharu is quite correct that it isn't always easy to actually implement. Consider how many ad-croc usages of 'restorecon' are needed to get a Fedora SELinux box through rc.sysinit: % grep restorecon /etc/rc.sysinit if [ -n "$SELINUX_STATE" -a -x /sbin/restorecon ] && LC_ALL=C fgrep -q " /dev " /proc/mounts ; then /sbin/restorecon -R /dev 2>/dev/null REBOOTFLAG=`restorecon -v /sbin/init` [ -n "$SELINUX_STATE" ] && restorecon /dev/pts >/dev/null 2>&1 [ -n "$SELINUX_STATE" ] && restorecon /dev/mapper /dev/mapper/control >/dev/null 2>&1 [ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path" [ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path" [ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path" restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/resolv.conf >/dev/null 2>&1 [ -n "$SELINUX_STATE" ] && restorecon /tmp [ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1 And that's just getting the system up to single-user. Things like sendmail and sshd require more restorecon handholding in their rc.init files. Or just look at the creeping horror that is 'restorecond' (in particular, consider that the default restorcond.conf contains the strings '~/public_html' and '~/.mozilla/plugins/libflashplayer.so'. Yee. Frikkin. Hah. ;) pgpwsOZJbbmzZ.pgp Description: PGP signature
Re: PCIE
David Miller wrote: > >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. > > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. There are systems which only get a single bit indication that an MSI has happened. Presumably we need something like IRQF_MSI which can be set as appropriate depending on the architecture? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AFS: Implement file locking
On Sun, May 27, 2007 at 12:55:30AM +0100, David Howells wrote:
> J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> > > + if (!afs_lock_manager) {
> > > + afs_lock_manager = create_singlethread_workqueue("kafs_lockd");
> > > + if (!afs_lock_manager)
> > > + return -ENOMEM;
> > > + }
> > > + return 0;
> >
> > Doesn't this need some locking?
>
> Oops. Yes. It used to be inside the lock_kernel() section, but has since
> escaped.
The BKL wouldn't help, since create_singlethread_workqueue() can sleep.
Or am I missing something?
> > Do you allow upgrades and downgrades? (Just curious.)
>
> AFS does not, as far as I know.
So if I request a write lock while holding a read lock, my request will
be denied?
> > > + /* if we've already got a readlock on the server and no waiting
> > > + * writelocks, then we might be able to instantly grant another
> >
> > Is that comment correct? (You don't really test for "waiting
> > writelocks", do you?)
>
> Locally, yes. 'if (list_empty(>pending_locks))' covers it quite
> handily.
Oops, right, I was overlooking that check.
This is a little strange, though--if there's somebody waiting for a
write lock on an inode (because somebody else already holds a read lock
on it), that shouldn't block requests for read locks.
--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote: 2007/5/27, James Morris <[EMAIL PROTECTED]>: On Sat, 26 May 2007, Kyle Moffett wrote: AppArmor). On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). Object labeling (or labeled security) looks simple and straight forward way, but it's not. (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. That's a circular argument, and a fairly trivial one at that. If you can't properly manage your labels, then how do you expect any security at all? If you can't manage your "labels", then pathname- based security won't work either. This is analogous to saying "Pathname-based security has an assumption that path-permissions are always properly defined and maintained", which is equally obvious. If you can't achieve the first with reasonable security, then you probably can't achieve the second either. Also, if you can't manage correct object labeling then I'm very interested in how you are maintaining secure Linux systems without standard DAC. (2) Also, assigning a label is something like inventing and assigning a *new* name (label name) to objects which can cause flaws. I don't understand how assigning new attributes to objects "can cause flaws", nor what flaws those might be; could you elaborate further? In particular, I don't see how this is really all that more complicated than defining additional access control in apache .htaccess files. The principle is the same: by stacking multiple independent security-verification mechanisms (Classical UNIX DAC and Apache permissions) you can increase security, albeit at an increased management cost. You might also note that ".htaccess" files are yet another form of successful "label-based" security; the security context for a directory depends on the .htaccess "label" file found within. The *exact* same principles apply to SELinux: you add additional attributes backed by a simple and powerful state- machine. The cross-checks are lower-level than those from .htaccess files, but the principles are the same. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCIE
On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote: > David Miller wrote: > > True, on sparc64 PCI-E controllers, for example, the MSI vector is > > received by the PCI-E host controller, and the host controller turns > > this into a cpu format interrupt packet for the system bus. > > Err .. why would a PCIe controller be CPU specific ? Looking at Figure > 1-6 of the spec, i think it should be CPU independent ? To be pedantic, the PCIe controller isn't really CPU specific. It's host bus specific. ie the PCI-e controller is a bridge between whatever chipset defines the "cache coherency domain" and the PCI-e devices. > Excuse me for my ignorance, just that my head has begun to reel after > reading through PCIe 1.0 and the device specs, still being inconclusive > how to proceed. no problem...I suspect you need to figure out why DTL-MMIO isn't working. I have never touched DTL and can't be of much help with that. hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [stable][PATCH] pci: quirk disable MSI on via vt3351
On Sun, 27 May 2007 02:20:52 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sat, May 26, 2007 at 05:01:04PM -0500, Jay Cliburn wrote:
> >
> > The Via VT3351 APIC does not play well with MSI and unleashes a
> > flood of APIC errors when MSI is used to deliver interrupts. The
> > problem was recently exposed when the atl1 network device driver,
> > which enables MSI by default, stimulated APIC errors on an Asus M2V
> > mainboard, which employs the Via VT3351.
> > See http://bugzilla.kernel.org/show_bug.cgi?id=8472 for additional
> > details on this bug.
> >...
>
> Please get patches included in Linus' tree _before_ submitting them
> for -stable.
>
> Adding a fix to 2.6.21 that is not yet in 2.6.22-rc would create a
> regression in 2.6.22.
Okay, thanks Adrian. I didn't realize I was making a mistake. I've
been waiting for the below patch to make it upstream, but it landed
in stable first, so I guess there's a regression as you indicate. My
patch depends upon this one.
Subject: [patch 41/69] pci-quirks: disable MSI on RS400-200 and RS480
Date: Mon, 21 May 2007 12:16:53 -0700
Sender: [EMAIL PROTECTED]
User-Agent: quilt/0.46-1
-stable review patch. If anyone has any objections, please let us know.
-
From: Tejun Heo <[EMAIL PROTECTED]>
MSI doesn't work on RS400-200 and RS480 requiring pci=nomsi kernel boot
parameter for ahci to work. This patch renames quirk_svw_msi() to
quirk_disable_all_msi() and use it to disable MSI on those chips.
http://thread.gmane.org/gmane.linux.ide/17820
http://thread.gmane.org/gmane.linux.ide/17516
https://bugzilla.novell.com/show_bug.cgi?id=263893
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Matí-as Alejandro Torres <[EMAIL PROTECTED]>
Cc: Greg K-H <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- linux-2.6.21.1.orig/drivers/pci/quirks.c
+++ linux-2.6.21.1/drivers/pci/quirks.c
@@ -1737,18 +1737,20 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_N
quirk_nvidia_ck804_pcie_aer_ext_cap);
#ifdef CONFIG_PCI_MSI
-/* The Serverworks PCI-X chipset does not support MSI. We cannot
easily rely
- * on setting PCI_BUS_FLAGS_NO_MSI in its bus flags because there are
actually
- * some other busses controlled by the chipset even if Linux is not
aware of it.
- * Instead of setting the flag on all busses in the machine, simply
disable MSI
- * globally.
+/* Some chipsets do not support MSI. We cannot easily rely on setting
+ * PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually
+ * some other busses controlled by the chipset even if Linux is not
+ * aware of it. Instead of setting the flag on all busses in the
+ * machine, simply disable MSI globally.
*/
-static void __init quirk_svw_msi(struct pci_dev *dev)
+static void __init quirk_disable_all_msi(struct pci_dev *dev)
{
pci_no_msi();
printk(KERN_WARNING "PCI: MSI quirk detected. MSI
deactivated.\n"); }
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_svw_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS,
PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480,
quirk_disable_all_msi); /* Disable MSI on chipsets that are known to
not support it */ static void __devinit quirk_disable_msi(struct
pci_dev *dev)
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Sat, 26 May 2007 15:58:50 PDT, Casey Schaufler said: > Fair enough, I don't believe that an argv[0] check ought to > be used as a security mechanism. I am not convinced that everyone > would agree with us. Having seen my share of argv[0]-related security bugs in my years, I have to agree that it's a security crock. As to why some might not agree, you already put your finger on it earlier: On Fri, 25 May 2007 12:06:19 PDT, Casey Schaufler said: > nefarious schemes. Remember that security is a subjective thing, and > using argv[0] and AppArmor together might make some people feel better. Some people would rather just feel better... pgp9UJGE57o5T.pgp Description: PGP signature
Re: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS
William Lee Irwin III wrote: Srivatsa Vaddagiri wrote: Ingo/Peter, any thoughts here? CFS and smpnice probably is "broken" with respect to such example as above albeit for nice-based tasks. On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote: See above. I think that faced with cpu affinity use by the system administrator that smpnice will tend towards a task to cpu allocation that is (close to) the best that can be achieved without violating the cpu affinity assignments. (It may take a little longer than normal but it should get there eventually.) You have to assume that the system administrator knows what (s)he's doing and is willing to accept the impact of their policy decision on the overall system performance. Having said that, if it was deemed necessary you could probably increase the speed at which the load balancer converged on a good result in the face of cpu affinity by keeping a "pinned weighted load" value for each run queue and using that to modify find_busiest_group() and find_busiest_queue() to be a bit smarter. But I'm not sure that it would be worth the added complexity. Just in case anyone was looking for algorithms... Lag should be considered in lieu of load because lag What's the definition of lag here? is what the scheduler is trying to minimize; This isn't always the case. Some may prefer fairness to minimal lag. Others may prefer particular tasks to receive preferential treatment. load is not directly relevant, but appears to have some sort of relationship. Also, instead of pinned, unpinned should be considered. If you have total and pinned you can get unpinned. It's probably cheaper to maintain data for pinned than unpinned as there's less of it on normal systems. It's unpinned that load balancing can actually migrate. True but see previous comment. Using the signed minimax pseudonorm (i.e. the highest signed lag, where positive is higher than all negative regardless of magnitude) on unpinned lags yields a rather natural load balancing algorithm consisting of migrating from highest to lowest signed lag, with progressively longer periods for periodic balancing across progressively higher levels of hierarchy in sched_domains etc. as usual. Basically skip over pinned tasks as far as lag goes. The trick with all that comes when tasks are pinned within a set of cpus (especially crossing sched_domains) instead of to a single cpu. Yes, this makes the cost of maintaining the required data higher which makes keeping pinned data more attractive than unpinned. BTW keeping data for sets of CPU affinities could cause problems as the number of possible sets is quite large (being 2 to the power of the number of CPUs). So you need an algorithm based on pinned data for single CPUs that knows the pinning isn't necessarily exclusive rather than one based on sets of CPUs. As I understand it (which may be wrong), the mechanism you describe below takes that approach. There one can just consider a cpu to enter a periodic load balance cycle, and then consider pushing and pulling, perhaps what could be called the "exchange lags" for the pair of cpus. That would be the minimax lag pseudonorms for the tasks migratable to both cpus of the pair. That makes the notion of moving things from highest to lowest lag (where load is now considered) unambiguous apart from whether all this converges, but not when to actually try to load balance vs. when not to, or when it's urgent vs. when it should be done periodically. To clarify that, an O(cpus**2) notion appears to be necessary, namely the largest exchange lag differential between any pair of cpus. There is also the open question of whether moving tasks between cpus with the highest exchange lag differential will actually reduce it or whether it runs the risk of increasing it by creating a larger exchange lag differential between different pairs of cpus. A similar open question is raised by localizing balancing decisions to sched_domains. What remains clear is that any such movement reduces the worst-case lag in the whole system. Because of that, the worst-case lag in the whole system monotonically decreases as balancing decisions are made, and that much is subject to an infinite descent argument. Unfortunately, determining the largest exchange lag differential appears to be more complex than merely finding the highest and lowest lags. Bipartite forms of the problem also arise from sched_domains. I doubt anyone's really paying any sort of attention, so I'll not really bother working out much more in the way of details with respect to load balancing. It may be that there are better ways to communicate algorithmic notions than prose descriptions. However, it's doubtful I'll produce anything in a timely enough fashion to attract or hold interest. The smpnice affair is better phrased in terms of task weighting. It's simple to honor nice in such an arrangement. First unravel the grouping
Re: PCIE
David Miller wrote: > From: Grant Grundler <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 18:16:31 -0600 > >> Are they really? The device is generating the transaction on the bus. >> The PCI host controller (in general) will be routing that transaction >> to wherever the "dest addr" of the MSI lives. It doesn't have to be >> in the CPU but it will certainly be a proxy for that CPU if it's not. >> We won't care if the proxy only have one IRQ line going to the CPU >> as long as the de-muxing of the "data" portion results in a unique >> identifier that can be mapped to exactly one interrupt handler. > > True, on sparc64 PCI-E controllers, for example, the MSI vector is > received by the PCI-E host controller, and the host controller turns > this into a cpu format interrupt packet for the system bus. Err .. why would a PCIe controller be CPU specific ? Looking at Figure 1-6 of the spec, i think it should be CPU independent ? Excuse me for my ignorance, just that my head has begun to reel after reading through PCIe 1.0 and the device specs, still being inconclusive how to proceed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc2: known regressions with patches
Michal Piotrowski wrote:
> File systems
>
> Subject: 2.6.21-git10/11: files getting truncated on xfs
> References : http://lkml.org/lkml/2007/5/9/410
> Submitter : Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Handled-By : David Chinner <[EMAIL PROTECTED]>
> Patch : http://lkml.org/lkml/2007/5/12/93
> Status : patch available
>
I'm satisfied the patch fixes the problem for me. Can we have some
movement to get it into at least -mm? This is a real, serious
data-corrupting bug. Ideally we should get it into -rc asap.
I've put the version I'm using below, but I haven't seen a properly
changelogged and signed-off version.
Thanks,
J
From: David Chinner <[EMAIL PROTECTED]>
On Sat, May 12, 2007 at 01:23:27PM +0200, Jan Engelhardt wrote:
>
> On May 10 2007 14:54, Jeremy Fitzhardinge wrote:
> What CPU architecture is this happening on? Not i686 with PAE by
> any chance?
>
> >>> Yes. Why?
> >>
> >> I have a bug report where NFS files are corrupted only with PAE clients.
> >> Corruption is at the end of the (newly untarred) files. Doesn't happen
> >> without PAE.
> >
> >Hm, suggestive, but I'm not convinced. Two differences to this situation:
> >
> > 1. Immediately after the clone ("untar"), the contents are completely
> > OK; it's only after a umount/mount cycle to problems appear
>
> And if you do a "sync" rather than umount/mount?
I doubt it will matter - I don't think we are marking the inode dirty at
the right point.
The change that was at fault modifies the way we update the file
size on the inode. We added an in-memory copy of the file size to
the in-memory copy of the disk inode's file size that we already
keep. We now only update the disk inode's (in memory copy) file size
on I/O completion. Because the generic code writes the inode out
before waiting for I/O to complete, the old file size gets written
out instead of the new one.
If the write was to extending the file into an existing block there
would be no delalloc transaction to redirty the inode (happens on
log I/O completion). Hence when the I/O completes and the file size
gets updated to the in-core disk inode (which is marked dirty), the
linux inode remains clean. As a result, a sync will never flush the
inode to get the updated file size to disk.
What I don't understand is that on unmount dirty xfs inodes get
written out. Clearly this is not happening - either there's a hole
in the writeback logic (unlikely - it was unchanged) or we've missed
some case where we need to update the filesize and mark the inode
dirty.
H - if the write was just a short append to the file, then the
block that was written to should already be mapped. Then we'll just
look up the extent by doing a BMAPI_READ lookup, set the type to
IOMAP_READ and add the block to ioend we are building.
The type IOMAP_READ determines the I/O completion behaviour - in this case
it is xfs_end_bio_read(), which fails to update the file size
Bingo.
A patch for you to try, Jeremy. I've just started a test run on it...
Cheers,
Dave.
---
fs/xfs/linux-2.6/xfs_aops.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
===
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c
@@ -973,8 +973,9 @@ xfs_page_state_convert(
bh = head = page_buffers(page);
offset = page_offset(page);
- flags = -1;
- type = IOMAP_READ;
+ iomap_valid = 0;
+ flags = BMAPI_READ;
+ type = IOMAP_NEW;
/* TODO: cleanup count and page_dirty */
@@ -1004,14 +1005,14 @@ xfs_page_state_convert(
*
* Third case, an unmapped buffer was found, and we are
* in a path where we need to write the whole page out.
-*/
+*/
if (buffer_unwritten(bh) || buffer_delay(bh) ||
((buffer_uptodate(bh) || PageUptodate(page)) &&
!buffer_mapped(bh) && (unmapped || startio))) {
- /*
+ /*
* Make sure we don't use a read-only iomap
*/
- if (flags == BMAPI_READ)
+ if (flags == BMAPI_READ)
iomap_valid = 0;
if (buffer_unwritten(bh)) {
@@ -1060,7 +1061,7 @@ xfs_page_state_convert(
* That means it must already have extents allocated
* underneath it. Map the extent by reading it.
*/
- if (!iomap_valid || type != IOMAP_READ) {
+ if (!iomap_valid || flags != BMAPI_READ) {
flags = BMAPI_READ;
size = xfs_probe_cluster(inode, page, bh,
Re: PCIE
From: Grant Grundler <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 18:16:31 -0600 > Are they really? The device is generating the transaction on the bus. > The PCI host controller (in general) will be routing that transaction > to wherever the "dest addr" of the MSI lives. It doesn't have to be > in the CPU but it will certainly be a proxy for that CPU if it's not. > We won't care if the proxy only have one IRQ line going to the CPU > as long as the de-muxing of the "data" portion results in a unique > identifier that can be mapped to exactly one interrupt handler. True, on sparc64 PCI-E controllers, for example, the MSI vector is received by the PCI-E host controller, and the host controller turns this into a cpu format interrupt packet for the system bus. I guess on IRQ pin starved systems, the PCI-E host controller or something similar would get interrogated by the cpu for the MSI vector number. I don't want to be the person who has to code up support for that, as it's not easy to shim mid-level vectoring into the generic IRQ layer currently. I'd love to be able to do that on sparc64 instead of what arch/sparc64/kernel/pci_sun4v.c's pci_sun4v_msi_prehandler() is doing. There is a lot of information and vectoring capabilities present that I'm simply not taking advantage of yet :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [stable][PATCH] pci: quirk disable MSI on via vt3351
On Sat, May 26, 2007 at 05:01:04PM -0500, Jay Cliburn wrote: > > The Via VT3351 APIC does not play well with MSI and unleashes a flood > of APIC errors when MSI is used to deliver interrupts. The problem > was recently exposed when the atl1 network device driver, which enables > MSI by default, stimulated APIC errors on an Asus M2V mainboard, which > employs the Via VT3351. > See http://bugzilla.kernel.org/show_bug.cgi?id=8472 for additional > details on this bug. >... Please get patches included in Linus' tree _before_ submitting them for -stable. Adding a fix to 2.6.21 that is not yet in 2.6.22-rc would create a regression in 2.6.22. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Extending boot protocol & bzImage for paravirt_ops
H. Peter Anvin wrote: > Pardon me for saying it, but it's hardly a hardship to add support for a > single additional constant in existing code. I'm starting to think this > argument is approaching not just the silly, but downright ridiculous. > Well, if the existing code is a standard libelf/libbfd, it could be tricky. > Another option is to have the ELF header at a nonzero offset. > Yes, that's exactly what I'm proposing. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCIE
On Sat, May 26, 2007 at 05:00:39PM -0700, David Miller wrote: > From: Grant Grundler <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 17:55:15 -0600 > > > MSI (and MSI-X) vectors are required to be exclusive. > > I submitted that change to pci.txt last year: > > http://lkml.org/lkml/2006/12/25/2 > > > > and ISTR I've posted that bit of the PCI spec a few years ago. > > But it probably was to linux-pci mailing list only. > > This requirement only extends to the PCI host controller, > how that interfaces to the cpu and it's limitations is > an entirely other matter. Are they really? The device is generating the transaction on the bus. The PCI host controller (in general) will be routing that transaction to wherever the "dest addr" of the MSI lives. It doesn't have to be in the CPU but it will certainly be a proxy for that CPU if it's not. We won't care if the proxy only have one IRQ line going to the CPU as long as the de-muxing of the "data" portion results in a unique identifier that can be mapped to exactly one interrupt handler. > > The cpus haven't been using interrupt pins for a long time now. > > Anything with a Local-xAPIC is already using transactions to > > signal interrupts even if the OS isn't aware of it. > > I'm not talking about x86, x86_64, et al. > > I'm talking about embedded ARM chips and the like, and yes they > very possibly will be using PCI-E controllers at some point. It doesn't matter if it's embedded or not. Trying to share what is the equivalent to an "edge triggered" interrupt is futile. MSI "vectors" need to be exclusive. thanks, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Extending boot protocol & bzImage for paravirt_ops
Rusty Russell wrote: > > hpa wrote: >> Do we have *any* environment that enters the 32-bit code with interrupts >> enabled? I would think that is unsafe no matter how you do it. > > Yeah, the cli there seems strange: maybe it's safe to simply delete it? > I suspect it was simply put there as a "belts and suspenders" kind of thing, which is perfectly appropriate. However, I would be highly surprised if it would have any users. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Extending boot protocol & bzImage for paravirt_ops
Jeremy Fitzhardinge wrote: > > I'd really prefer to keep an intact embedded ELF file rather than have a > semi-ELF file. That way it would be easier to simply load the image and > point the normal ELF machinery at some offset into the file rather than > having to have a special handler for "\x7fBZE" or whatever. > Pardon me for saying it, but it's hardly a hardship to add support for a single additional constant in existing code. I'm starting to think this argument is approaching not just the silly, but downright ridiculous. Another option is to have the ELF header at a nonzero offset. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AFS: Implement file locking
Kyle Moffett <[EMAIL PROTECTED]> wrote: > I was actually under the impression that OpenAFS had support for byte- > range locking (as well as lock upgrade/downgrade); As far as I know, there is no support for byte-range locking at all in the AFS protocol itself. The client can try to emulate byte-range locking locally, but that's about it. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Extending boot protocol & bzImage for paravirt_ops
On Sun, 2007-05-27 at 00:47 +0100, Jeremy Fitzhardinge wrote: > Rusty Russell wrote: > > You also want to skip the cli: perhaps a separate flag for this is > > appropriate though. > > > > Not a problem for Xen; it will be trapped+emulated (ie, ignored). Well, I could do that for lguest as a special case, I guess. Seems icky tho. hpa wrote: > Do we have *any* environment that enters the 32-bit code with interrupts > enabled? I would think that is unsafe no matter how you do it. Yeah, the cli there seems strange: maybe it's safe to simply delete it? Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCIE
From: Grant Grundler <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 17:55:15 -0600 > MSI (and MSI-X) vectors are required to be exclusive. > I submitted that change to pci.txt last year: > http://lkml.org/lkml/2006/12/25/2 > > and ISTR I've posted that bit of the PCI spec a few years ago. > But it probably was to linux-pci mailing list only. This requirement only extends to the PCI host controller, how that interfaces to the cpu and it's limitations is an entirely other matter. > > I can imagine many systems where the cpu simply doesn't have enough > > interrupt pins to uniquely identify every possible MSI interrupt > > source. > > The cpus haven't been using interrupt pins for a long time now. > Anything with a Local-xAPIC is already using transactions to > signal interrupts even if the OS isn't aware of it. I'm not talking about x86, x86_64, et al. I'm talking about embedded ARM chips and the like, and yes they very possibly will be using PCI-E controllers at some point. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] AFS: Implement file locking
J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> > + if (!afs_lock_manager) {
> > + afs_lock_manager = create_singlethread_workqueue("kafs_lockd");
> > + if (!afs_lock_manager)
> > + return -ENOMEM;
> > + }
> > + return 0;
>
> Doesn't this need some locking?
Oops. Yes. It used to be inside the lock_kernel() section, but has since
escaped.
> Do you allow upgrades and downgrades? (Just curious.)
AFS does not, as far as I know. Upgrades are dangerous anyway as you can get
deadlock quite easily.
> > + /* if we've already got a readlock on the server and no waiting
> > +* writelocks, then we might be able to instantly grant another
>
> Is that comment correct? (You don't really test for "waiting
> writelocks", do you?)
Locally, yes. 'if (list_empty(>pending_locks))' covers it quite
handily. I can't do anything about checking the server.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCIE
On Sat, May 26, 2007 at 03:49:10PM -0700, David Miller wrote: > From: Manu Abraham <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 19:03:12 +0400 > > > i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. MSI (and MSI-X) vectors are required to be exclusive. I submitted that change to pci.txt last year: http://lkml.org/lkml/2006/12/25/2 and ISTR I've posted that bit of the PCI spec a few years ago. But it probably was to linux-pci mailing list only. > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. The cpus haven't been using interrupt pins for a long time now. Anything with a Local-xAPIC is already using transactions to signal interrupts even if the OS isn't aware of it. hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] convert sata_qstor to new libata EH
This patch is an attempt to convert sata_qstor over to new EH.
It compiles, but I have not tested it. If anyone is willing to give
it an "it talks to the disks" test that would be great.
This is checked into the 'new-eh' branch of libata. Review requested.
drivers/ata/sata_qstor.c | 65 +--
1 file changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/ata/sata_qstor.c b/drivers/ata/sata_qstor.c
index 6688ccb..76ab39e 100644
--- a/drivers/ata/sata_qstor.c
+++ b/drivers/ata/sata_qstor.c
@@ -116,14 +116,15 @@ static void qs_scr_write (struct ata_port *ap, unsigned
int sc_reg, u32 val);
static int qs_ata_init_one (struct pci_dev *pdev, const struct pci_device_id
*ent);
static int qs_port_start(struct ata_port *ap);
static void qs_host_stop(struct ata_host *host);
-static void qs_phy_reset(struct ata_port *ap);
static void qs_qc_prep(struct ata_queued_cmd *qc);
static unsigned int qs_qc_issue(struct ata_queued_cmd *qc);
static int qs_check_atapi_dma(struct ata_queued_cmd *qc);
static void qs_bmdma_stop(struct ata_queued_cmd *qc);
static u8 qs_bmdma_status(struct ata_port *ap);
static void qs_irq_clear(struct ata_port *ap);
-static void qs_eng_timeout(struct ata_port *ap);
+static void qs_freeze(struct ata_port *ap);
+static void qs_thaw(struct ata_port *ap);
+static void qs_error_handler(struct ata_port *ap);
static struct scsi_host_template qs_ata_sht = {
.module = THIS_MODULE,
@@ -152,11 +153,12 @@ static const struct ata_port_operations qs_ata_ops = {
.check_atapi_dma= qs_check_atapi_dma,
.exec_command = ata_exec_command,
.dev_select = ata_std_dev_select,
- .phy_reset = qs_phy_reset,
.qc_prep= qs_qc_prep,
.qc_issue = qs_qc_issue,
.data_xfer = ata_data_xfer,
- .eng_timeout= qs_eng_timeout,
+ .freeze = qs_freeze,
+ .thaw = qs_thaw,
+ .error_handler = qs_error_handler,
.irq_clear = qs_irq_clear,
.irq_on = ata_irq_on,
.irq_ack= ata_irq_ack,
@@ -172,8 +174,6 @@ static const struct ata_port_info qs_port_info[] = {
/* board_2068_idx */
{
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
- ATA_FLAG_SATA_RESET |
- //FIXME ATA_FLAG_SRST |
ATA_FLAG_MMIO | ATA_FLAG_PIO_POLLING,
.pio_mask = 0x10, /* pio4 */
.udma_mask = 0x7f, /* udma0-6 */
@@ -236,23 +236,35 @@ static inline void qs_reset_channel_logic(struct ata_port
*ap)
qs_enter_reg_mode(ap);
}
-static void qs_phy_reset(struct ata_port *ap)
+static void qs_freeze(struct ata_port *ap)
{
- struct qs_port_priv *pp = ap->private_data;
+ u8 __iomem *mmio_base = qs_mmio_base(ap->host);
- pp->state = qs_state_idle;
- qs_reset_channel_logic(ap);
- sata_phy_reset(ap);
+ writeb(0, mmio_base + QS_HCT_CTRL); /* disable host interrupts */
+}
+
+static void qs_thaw(struct ata_port *ap)
+{
+ u8 __iomem *mmio_base = qs_mmio_base(ap->host);
+
+ writeb(1, mmio_base + QS_HCT_CTRL); /* enable host interrupts */
}
-static void qs_eng_timeout(struct ata_port *ap)
+static int qs_prereset(struct ata_port *ap, unsigned long deadline)
{
struct qs_port_priv *pp = ap->private_data;
if (pp->state != qs_state_idle) /* healthy paranoia */
pp->state = qs_state_mmio;
qs_reset_channel_logic(ap);
- ata_eng_timeout(ap);
+
+ return ata_std_prereset(ap, deadline);
+}
+
+static void qs_error_handler(struct ata_port *ap)
+{
+ ata_do_eh(ap, qs_prereset, ata_std_softreset, NULL,
+ ata_std_postreset);
}
static u32 qs_scr_read (struct ata_port *ap, unsigned int sc_reg)
@@ -359,7 +371,6 @@ static unsigned int qs_qc_issue(struct ata_queued_cmd *qc)
switch (qc->tf.protocol) {
case ATA_PROT_DMA:
-
pp->state = qs_state_pkt;
qs_packet_start(qc);
return 0;
@@ -376,6 +387,26 @@ static unsigned int qs_qc_issue(struct ata_queued_cmd *qc)
return ata_qc_issue_prot(qc);
}
+static void qs_do_or_die(struct ata_queued_cmd *qc, u8 status)
+{
+ qc->err_mask |= ac_err_mask(status);
+
+ if (!qc->err_mask)
+ ata_qc_complete(qc);
+ else {
+ struct ata_port *ap = qc->ap;
+ struct ata_eh_info *ehi = >eh_info;
+
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_push_desc(ehi, "status 0x%02X", status);
+
+ if (qc->err_mask == AC_ERR_DEV)
+ ata_port_abort(ap);
+ else
+ ata_port_freeze(ap);
+ }
+}
+
static inline
[PATCH] Remove the last few UMSDOS leftovers
(sorry about the long Cc: list for such a trivial patch, but I wanted to
include everyone who's stuff I'm changing)
The UMSDOS filesystem was removed back in 2.6.11, but some tiny bits
stuck around. This patch removes the few leftovers.
The only things left behind after this are the entries in the CREDITS file
and the ioctl number in Documentation/ioctl-number.txt as documentation.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
Documentation/ioctl-number.txt |2 +-
arch/arm26/defconfig |1 -
arch/cris/arch-v10/defconfig |1 -
arch/um/config.release |1 -
include/linux/ncp_fs.h |2 --
5 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 3de7d37..5c7fbf9 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -67,7 +67,7 @@ Code Seq#Include FileComments
0x00 00-1F linux/wavefront.h conflict!
0x02 all linux/fd.h
0x03 all linux/hdreg.h
-0x04 all linux/umsdos_fs.h
+0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse.
0x06 all linux/lp.h
0x09 all linux/md.h
0x12 all linux/fs.h
diff --git a/arch/arm26/defconfig b/arch/arm26/defconfig
index c4a8970..2b7d44b 100644
--- a/arch/arm26/defconfig
+++ b/arch/arm26/defconfig
@@ -248,7 +248,6 @@ CONFIG_I2C_CHARDEV=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
-# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
diff --git a/arch/cris/arch-v10/defconfig b/arch/cris/arch-v10/defconfig
index 2a3411e..710c20b 100644
--- a/arch/cris/arch-v10/defconfig
+++ b/arch/cris/arch-v10/defconfig
@@ -429,7 +429,6 @@ CONFIG_NET_ETHERNET=y
# CONFIG_BFS_FS is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
-# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
diff --git a/arch/um/config.release b/arch/um/config.release
index fc68bcb..aba42f8 100644
--- a/arch/um/config.release
+++ b/arch/um/config.release
@@ -200,7 +200,6 @@ CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
-CONFIG_UMSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_EFS_FS=m
# CONFIG_JFFS_FS is not set
diff --git a/include/linux/ncp_fs.h b/include/linux/ncp_fs.h
index 83e39eb..88766e4 100644
--- a/include/linux/ncp_fs.h
+++ b/include/linux/ncp_fs.h
@@ -148,8 +148,6 @@ struct ncp_nls_ioctl
#include
#include
-/* undef because public define in umsdos_fs.h (ncp_fs.h isn't public) */
-#undef PRINTK
/* define because it is easy to change PRINTK to {*}PRINTK */
#define PRINTK(format, args...) printk(KERN_DEBUG format , ## args)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Documentation on /sys/power/resume
Not in the ABI doc, is there and doc at all, and if not could someone who knows where it's used might give me a hint, as a quick look didn't bring enlightenment. Or is it a future hook which doesn't work yet? -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Extending boot protocol & bzImage for paravirt_ops
Eric W. Biederman wrote: >> What was the problem with ELF bzImage? Is it confirmed to be >> problematic, or just suspected? >> > > There was a problem, Andrews machine would not the kernel with the ELF > header. It was not root caused. So we are not certain why. > The Vaio? Do you think we could use it as kindling when we "deal with" James's Voyagers? >> Could we end up using a plain ELF file >> (which would be easiest for me, since I think the existing ELF domain >> builder could pretty much deal with that as-is). >> > > I think we should start there and be prepared to munge the ELF > magic number if there are problems. Placing ELF notes is going > to require a little work but mostly it should be a matter of > copying the from vmlinux. > I'd really prefer to keep an intact embedded ELF file rather than have a semi-ELF file. That way it would be easier to simply load the image and point the normal ELF machinery at some offset into the file rather than having to have a special handler for "\x7fBZE" or whatever. > Most of that though is just packaging. The meat of the issue > is how do we upgrade the bootloader data. Do the changes > below sound like everything we need? > How does the kernel specify what memory it requires to be mapped (both for the image itself, and for any memory it needs to use to decompress/relocate the final kernel image). If its by using ELF Phdrs, then we need to: 1. specify the constraints on what mappings are allowed, 2. specify how the bootloader uses the mappings, and 3. specify how the ELF file is to be found. If the bzImage is really a plain ELF file, then 3 is a non-issue. Otherwise, should we allocate a field which specifies the offset of the ELF header within the bzImage, and make all offsets contained in the ELF header relative to the header itself rather than the overall bzImage? As far as 1 and 2 go, I propose: Requirements on the Phdrs in the image: 1. the Phdrs must map the actual bzImage code and data, with appropriate filesz and memsz 2. the Phdrs must also map all the other memory needed to decompress/relocate the kernel, with filesz=0 and memsz set appropriately 3. the Phdr mappings must always be 1:1 (ie, P=V), and RW(X) 4. the mappings must be as low as possible, to avoid any hole the hypervisor requires (if the mappings are too high, the bootloader may just fail to start the kernel) Requirements for the bootloader: 1. it is always correct for the bootloader to simply leave paging disabled; presumably the subarch will tell the kernel that it needs to set up its own initial mappings 2. if paging is enabled, the bootloader creates mappings: 1. with PAE set to match the kernel's requirements (this suggests that loadflags should have a PAE/non-PAE flag) 2. all mappings are RWX (ie, RW, no NX) [ rationale: this means we don't need to deal with pages of different types/permissions at this stage of booting, which might be especially awkward when recycling pages ] 3. mappings covering at least the ones specified by the Phdrs, but it is acceptible to over-map (for example, map the entire address space) 4. Other non-1:1 mappings may exist outside the image's Phdrs (for example, containing the initial pagetables, hypervisor address space, and other mappings) > Field name: loadflags > Type:modify (obligatory) > Offset/size: 0x211/1 > Protocol:2.00+ > >This field is a bitmask. > >Bit 0 (read): LOADED_HIGH > - If 0, the protected-mode code is loaded at 0x1. > - If 1, the protected-mode code is loaded at 0x10. > + Bit 5 (read): PAE mode +If the bootloader starts kernel with paging enabled, then: +- if 0, enable non-PAE mode paging +- if 1, enable PAE mode paging > + Bit 6 (write): KEEP_SEGMENTS > + Protocol: 2.07+ > + - if 0, reload the segment registers in the 32bit entry point. > So does this mean the bootloader has set up a kernel-compatible GDT? Or does it also mean "set up a GDT"? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Extending boot protocol & bzImage for paravirt_ops
Rusty Russell wrote: > You also want to skip the cli: perhaps a separate flag for this is > appropriate though. > Not a problem for Xen; it will be trapped+emulated (ie, ignored). J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] MIPS: Transform old-style macros to newer "__noreturn" standard.
H. Peter Anvin wrote: > Robert P. J. Day wrote: >> It does not make sense for a noreturn function to have a return type >> other than void. >> ^ >> === >> >> so I'm just going to stick with the pattern that's been used so far. >> i realize it offends your sense of syntactic sensibility, but it's >> just not worth treating that one attribute so differently from the >> rest of them. >> > > Why are you so hung up over the fact that the *implementation* of this > is an attribute? You're totally confusing interface and implementation. > Perhaps I should clarify this: The whole reason to abstract this as a macro *at all* is to take it away from the specific implementation in gcc. Thus, implementing an inferior interface just because gcc happens to do it that way is actively counterproductive. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7 RESEND] cxgb3 - Update FW to 4.1
From: Divy Le Ray <[EMAIL PROTECTED]>
Bump FW version to 4.1.
Modify chip tuning in consequence.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/regs.h|4
drivers/net/cxgb3/t3_hw.c | 40 ++--
drivers/net/cxgb3/version.h |2 +-
3 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index bf9d6be..2c47d4a 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1160,6 +1160,8 @@
#define A_TP_MOD_CHANNEL_WEIGHT 0x434
+#define A_TP_MOD_RATE_LIMIT 0x438
+
#define A_TP_PIO_ADDR 0x440
#define A_TP_PIO_DATA 0x444
@@ -1214,6 +1216,8 @@
#define G_TXDROPCNTCH0RCVD(x) (((x) >> S_TXDROPCNTCH0RCVD) & \
M_TXDROPCNTCH0RCVD)
+#define A_TP_PROXY_FLOW_CNTL 0x4b0
+
#define A_ULPRX_CTL 0x500
#define S_ROUND_ROBIN4
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index fb485d0..4929ac9 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -921,7 +921,7 @@ static int t3_flash_erase_sectors(struct
/*
* t3_load_fw - download firmware
* @adapter: the adapter
- * @fw_data: the firrware image to write
+ * @fw_data: the firmware image to write
* @size: image size
*
* Write the supplied firmware image to the card's serial flash.
@@ -2362,7 +2362,7 @@ static void tp_config(struct adapter *ad
F_TCPCHECKSUMOFFLOAD | V_IPTTL(64));
t3_write_reg(adap, A_TP_TCP_OPTIONS, V_MTUDEFAULT(576) |
F_MTUENABLE | V_WINDOWSCALEMODE(1) |
-V_TIMESTAMPSMODE(1) | V_SACKMODE(1) | V_SACKRX(1));
+V_TIMESTAMPSMODE(0) | V_SACKMODE(1) | V_SACKRX(1));
t3_write_reg(adap, A_TP_DACK_CONFIG, V_AUTOSTATE3(1) |
V_AUTOSTATE2(1) | V_AUTOSTATE1(0) |
V_BYTETHRESHOLD(16384) | V_MSSTHRESHOLD(2) |
@@ -2371,16 +2371,18 @@ static void tp_config(struct adapter *ad
F_IPV6ENABLE | F_NICMODE);
t3_write_reg(adap, A_TP_TX_RESOURCE_LIMIT, 0x18141814);
t3_write_reg(adap, A_TP_PARA_REG4, 0x5050105);
- t3_set_reg_field(adap, A_TP_PARA_REG6,
-adap->params.rev > 0 ? F_ENABLEESND : F_T3A_ENABLEESND,
-0);
+ t3_set_reg_field(adap, A_TP_PARA_REG6, 0,
+adap->params.rev > 0 ? F_ENABLEESND :
+F_T3A_ENABLEESND);
t3_set_reg_field(adap, A_TP_PC_CONFIG,
-F_ENABLEEPCMDAFULL | F_ENABLEOCSPIFULL,
-F_TXDEFERENABLE | F_HEARBEATDACK | F_TXCONGESTIONMODE |
-F_RXCONGESTIONMODE);
+F_ENABLEEPCMDAFULL,
+F_ENABLEOCSPIFULL |F_TXDEFERENABLE | F_HEARBEATDACK |
+F_TXCONGESTIONMODE | F_RXCONGESTIONMODE);
t3_set_reg_field(adap, A_TP_PC_CONFIG2, F_CHDRAFULL, 0);
-
+ t3_write_reg(adap, A_TP_PROXY_FLOW_CNTL, 1080);
+ t3_write_reg(adap, A_TP_PROXY_FLOW_CNTL, 1000);
+
if (adap->params.rev > 0) {
tp_wr_indirect(adap, A_TP_EGRESS_CONFIG, F_REWRITEFORCETOSIZE);
t3_set_reg_field(adap, A_TP_PARA_REG3, F_TXPACEAUTO,
@@ -2390,9 +2392,10 @@ static void tp_config(struct adapter *ad
} else
t3_set_reg_field(adap, A_TP_PARA_REG3, 0, F_TXPACEFIXED);
- t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT1, 0x12121212);
- t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT0, 0x12121212);
- t3_write_reg(adap, A_TP_MOD_CHANNEL_WEIGHT, 0x1212);
+ t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT1, 0);
+ t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT0, 0);
+ t3_write_reg(adap, A_TP_MOD_CHANNEL_WEIGHT, 0);
+ t3_write_reg(adap, A_TP_MOD_RATE_LIMIT, 0xf220);
}
/* Desired TP timer resolution in usec */
@@ -2468,6 +2471,7 @@ int t3_tp_set_coalescing_size(struct ada
val |= F_RXCOALESCEENABLE;
if (psh)
val |= F_RXCOALESCEPSHEN;
+ size = min(MAX_RX_COALESCING_LEN, size);
t3_write_reg(adap, A_TP_PARA_REG2, V_RXCOALESCESIZE(size) |
V_MAXRXDATA(MAX_RX_COALESCING_LEN));
}
@@ -2497,10 +2501,10 @@ static void __devinit init_mtus(unsigned
* are enabled and still have at least 8 bytes of payload.
*/
mtus[0] = 88;
- mtus[1] = 256;
- mtus[2] = 512;
- mtus[3] = 576;
- mtus[4] = 808;
+ mtus[1] = 88;
+ mtus[2] = 256;
+ mtus[3] = 512;
+ mtus[4] = 576;
mtus[5] = 1024;
mtus[6] = 1280;
mtus[7] = 1492;
@@ -2802,7 +2806,7 @@ static void init_hw_for_avail_ports(stru
t3_set_reg_field(adap, A_ULPTX_CONFIG, F_CFG_RR_ARB, 0);
t3_write_reg(adap, A_MPS_CFG, F_TPRXPORTEN | F_TPTXPORT0EN |
Re: [PATCH 4/7] cxgb3 - Update FW to 4.1
Michael Buesch wrote: On Sunday 27 May 2007 01:00:04 [EMAIL PROTECTED] wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Bump FW version to 4.1. Modify chip tuning in consequence. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- @@ -2496,11 +2500,11 @@ static void __devinit init_mtus(unsigned * it can accomodate max size TCP/IP headers when SACK and timestamps * are enabled and still have at least 8 bytes of payload. */ - mtus[0] = 88; - mtus[1] = 256; - mtus[2] = 512; - mtus[3] = 576; - mtus[4] = 808; + mtus[1] = 88; + mtus[1] = 88; looks like a typo. Good catch. The intent was to set mtu[0] and mtu[1] to 88. I'll resubmit this patch. Thanks! Divy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
2007/5/27, James Morris <[EMAIL PROTECTED]>: On Sat, 26 May 2007, Kyle Moffett wrote: > AppArmor). On the other hand, if you actually want to protect the _data_, > then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). Object labeling (or labeled security) looks simple and straight forward way, but it's not. (1) Object labeling has a assumption that labels are always properly defined and maintained. This can not be easily achieved. (2) Also, assigning a label is something like inventing and assigning a *new* name (label name) to objects which can cause flaws. I'm not saying labeled security or SELinux is wrong. I just wanted to remind that the important part is the "process" not the "result". :-) -- Toshiharu Harada [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/
[PATCH] convert pdc_adma to new libata EH
This patch is an attempt to convert pdc_adma over to new EH. It
compiles, but I have not tested it. If anyone is willing to give it an
"it talks to the disks" test that would be great.
This hardware is -mostly- compatible with the docs on
http://www.T13.org/ (look for d1510r1) according to Mark, IIRC.
This is checked into the 'new-eh' branch of libata. Review requested.
drivers/ata/pdc_adma.c | 98 +
1 file changed, 75 insertions(+), 23 deletions(-)
diff --git a/drivers/ata/pdc_adma.c b/drivers/ata/pdc_adma.c
index f12c2b6..5195f3f 100644
--- a/drivers/ata/pdc_adma.c
+++ b/drivers/ata/pdc_adma.c
@@ -92,6 +92,8 @@ enum {
/* CPB bits */
cDONE = (1 << 0),
+ cATERR = (1 << 3),
+
cVLD= (1 << 0),
cDAT= (1 << 2),
cIEN= (1 << 3),
@@ -131,46 +133,48 @@ static int adma_ata_init_one (struct pci_dev *pdev,
static int adma_port_start(struct ata_port *ap);
static void adma_host_stop(struct ata_host *host);
static void adma_port_stop(struct ata_port *ap);
-static void adma_phy_reset(struct ata_port *ap);
static void adma_qc_prep(struct ata_queued_cmd *qc);
static unsigned int adma_qc_issue(struct ata_queued_cmd *qc);
static int adma_check_atapi_dma(struct ata_queued_cmd *qc);
static void adma_bmdma_stop(struct ata_queued_cmd *qc);
static u8 adma_bmdma_status(struct ata_port *ap);
static void adma_irq_clear(struct ata_port *ap);
-static void adma_eng_timeout(struct ata_port *ap);
+static void adma_freeze(struct ata_port *ap);
+static void adma_thaw(struct ata_port *ap);
+static void adma_error_handler(struct ata_port *ap);
static struct scsi_host_template adma_ata_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
.ioctl = ata_scsi_ioctl,
.queuecommand = ata_scsi_queuecmd,
+ .slave_configure= ata_scsi_slave_config,
+ .slave_destroy = ata_scsi_slave_destroy,
+ .bios_param = ata_std_bios_param,
+ .proc_name = DRV_NAME,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
.sg_tablesize = LIBATA_MAX_PRD,
+ .dma_boundary = ADMA_DMA_BOUNDARY,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
- .emulated = ATA_SHT_EMULATED,
.use_clustering = ENABLE_CLUSTERING,
- .proc_name = DRV_NAME,
- .dma_boundary = ADMA_DMA_BOUNDARY,
- .slave_configure= ata_scsi_slave_config,
- .slave_destroy = ata_scsi_slave_destroy,
- .bios_param = ata_std_bios_param,
+ .emulated = ATA_SHT_EMULATED,
};
static const struct ata_port_operations adma_ata_ops = {
.port_disable = ata_port_disable,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
- .check_status = ata_check_status,
- .check_atapi_dma= adma_check_atapi_dma,
.exec_command = ata_exec_command,
+ .check_status = ata_check_status,
.dev_select = ata_std_dev_select,
- .phy_reset = adma_phy_reset,
+ .check_atapi_dma= adma_check_atapi_dma,
+ .data_xfer = ata_data_xfer,
.qc_prep= adma_qc_prep,
.qc_issue = adma_qc_issue,
- .eng_timeout= adma_eng_timeout,
- .data_xfer = ata_data_xfer,
+ .freeze = adma_freeze,
+ .thaw = adma_thaw,
+ .error_handler = adma_error_handler,
.irq_clear = adma_irq_clear,
.irq_on = ata_irq_on,
.irq_ack= ata_irq_ack,
@@ -273,24 +277,41 @@ static inline void adma_enter_reg_mode(struct ata_port
*ap)
readb(chan + ADMA_STATUS); /* flush */
}
-static void adma_phy_reset(struct ata_port *ap)
+static void adma_freeze(struct ata_port *ap)
{
- struct adma_port_priv *pp = ap->private_data;
+ void __iomem *chan = ADMA_PORT_REGS(ap);
+
+ /* mask/clear ATA interrupts */
+ writeb(ATA_NIEN, ap->ioaddr.ctl_addr);
+ ata_check_status(ap);
+
+ /* reset ADMA to idle state */
+ writew(aPIOMD4 | aNIEN | aRSTADM, chan + ADMA_CONTROL);
+ udelay(2);
+ writew(aPIOMD4 | aNIEN, chan + ADMA_CONTROL);
+ udelay(2);
+}
- pp->state = adma_state_idle;
+static void adma_thaw(struct ata_port *ap)
+{
adma_reinit_engine(ap);
- ata_port_probe(ap);
- ata_bus_reset(ap);
}
-static void adma_eng_timeout(struct ata_port *ap)
+static int adma_prereset(struct ata_port *ap, unsigned long deadline)
{
struct adma_port_priv
Re: [PATCH 4/7] cxgb3 - Update FW to 4.1
On Sunday 27 May 2007 01:00:04 [EMAIL PROTECTED] wrote: > From: Divy Le Ray <[EMAIL PROTECTED]> > > Bump FW version to 4.1. > Modify chip tuning in consequence. > > Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> > --- > @@ -2496,11 +2500,11 @@ static void __devinit init_mtus(unsigned >* it can accomodate max size TCP/IP headers when SACK and timestamps >* are enabled and still have at least 8 bytes of payload. >*/ > - mtus[0] = 88; > - mtus[1] = 256; > - mtus[2] = 512; > - mtus[3] = 576; > - mtus[4] = 808; > + mtus[1] = 88; > + mtus[1] = 88; looks like a typo. > + mtus[2] = 256; > + mtus[3] = 512; > + mtus[4] = 576; > mtus[5] = 1024; > mtus[6] = 1280; > mtus[7] = 1492; -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: epoll,threading
> Hello all, > > I want to know in detail about , what the events (epoll or /dev/poll or > select ) achieve in contrast to thread per client. > > i can have a thread per client and use send and recv system call directly > right? Why do i go for these event mechanisms? > > Please help me to understand this. Aside from the obvious, consider a server that needs to do a little bit of work on each of 1,000 clients on a single CPU system. With a thread-per-client approach, 1,000 context switches will be needed. With an epoll thread pool approach, none are needed and five or six are typical. Both get you the major advantages of threading. You can take full advantage of multiple CPUs. You can write code that blocks occasionally without bringing the whole server down. A page fault doesn't stall your whole server. 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/
[PATCH 5/7] cxgb3 - Stop mac RX when changing MTU
From: Divy Le Ray <[EMAIL PROTECTED]>
Rx traffic needs to be halted when the MTU is changed
to avoid a potential chip hang.
Reset/restore MAC filters around a MTU change.
Also fix the pause frames high materwark setting.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/regs.h |4 +++
drivers/net/cxgb3/xgmac.c | 67 -
2 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index 2c47d4a..02f8731 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1886,6 +1886,10 @@
#define V_COPYALLFRAMES(x) ((x) << S_COPYALLFRAMES)
#define F_COPYALLFRAMESV_COPYALLFRAMES(1U)
+#define S_DISBCAST1
+#define V_DISBCAST(x) ((x) << S_DISBCAST)
+#define F_DISBCASTV_DISBCAST(1U)
+
#define A_XGM_RX_HASH_LOW 0x814
#define A_XGM_RX_HASH_HIGH 0x818
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net/cxgb3/xgmac.c
index a506792..16cadba 100644
--- a/drivers/net/cxgb3/xgmac.c
+++ b/drivers/net/cxgb3/xgmac.c
@@ -231,6 +231,28 @@ int t3_mac_set_num_ucast(struct cmac *ma
return 0;
}
+static void disable_exact_filters(struct cmac *mac)
+{
+ unsigned int i, reg = mac->offset + A_XGM_RX_EXACT_MATCH_LOW_1;
+
+ for (i = 0; i < EXACT_ADDR_FILTERS; i++, reg += 8) {
+ u32 v = t3_read_reg(mac->adapter, reg);
+ t3_write_reg(mac->adapter, reg, v);
+ }
+ t3_read_reg(mac->adapter, A_XGM_RX_EXACT_MATCH_LOW_1); /* flush */
+}
+
+static void enable_exact_filters(struct cmac *mac)
+{
+ unsigned int i, reg = mac->offset + A_XGM_RX_EXACT_MATCH_HIGH_1;
+
+ for (i = 0; i < EXACT_ADDR_FILTERS; i++, reg += 8) {
+ u32 v = t3_read_reg(mac->adapter, reg);
+ t3_write_reg(mac->adapter, reg, v);
+ }
+ t3_read_reg(mac->adapter, A_XGM_RX_EXACT_MATCH_LOW_1); /* flush */
+}
+
/* Calculate the RX hash filter index of an Ethernet address */
static int hash_hw_addr(const u8 * addr)
{
@@ -281,6 +303,14 @@ int t3_mac_set_rx_mode(struct cmac *mac,
return 0;
}
+static int rx_fifo_hwm(int mtu)
+{
+ int hwm;
+
+ hwm = max(MAC_RXFIFO_SIZE - 3 * mtu, (MAC_RXFIFO_SIZE * 38) / 100);
+ return min(hwm, MAC_RXFIFO_SIZE - 8192);
+}
+
int t3_mac_set_mtu(struct cmac *mac, unsigned int mtu)
{
int hwm, lwm;
@@ -306,11 +336,38 @@ int t3_mac_set_mtu(struct cmac *mac, uns
lwm = min(3 * (int)mtu, MAC_RXFIFO_SIZE / 4);
v = t3_read_reg(adap, A_XGM_RXFIFO_CFG + mac->offset);
+ if (adap->params.rev == T3_REV_B2 &&
+ (t3_read_reg(adap, A_XGM_RX_CTRL + mac->offset) & F_RXEN)) {
+ disable_exact_filters(mac);
+ t3_set_reg_field(adap, A_XGM_RXFIFO_CFG + mac->offset,
+F_ENHASHMCAST | F_COPYALLFRAMES, F_DISBCAST);
+
+ /* drain rx FIFO */
+ if (t3_wait_op_done(adap,
+ A_XGM_RX_MAX_PKT_SIZE_ERR_CNT +
+ mac->offset,
+ 1 << 31, 1, 20, 5)) {
+ t3_write_reg(adap, A_XGM_RXFIFO_CFG + mac->offset, v);
+ enable_exact_filters(mac);
+ return -EIO;
+ }
+ t3_write_reg(adap, A_XGM_RX_MAX_PKT_SIZE + mac->offset, mtu);
+ enable_exact_filters(mac);
+ } else
+ t3_write_reg(adap, A_XGM_RX_MAX_PKT_SIZE + mac->offset, mtu);
+
+ /*
+* Adjust the PAUSE frame watermarks. We always set the LWM, and the
+* HWM only if flow-control is enabled.
+*/
+ hwm = rx_fifo_hwm(mtu);
+ lwm = min(3 * (int)mtu, MAC_RXFIFO_SIZE / 4);
v &= ~V_RXFIFOPAUSELWM(M_RXFIFOPAUSELWM);
v |= V_RXFIFOPAUSELWM(lwm / 8);
if (G_RXFIFOPAUSEHWM(v))
v = (v & ~V_RXFIFOPAUSEHWM(M_RXFIFOPAUSEHWM)) |
V_RXFIFOPAUSEHWM(hwm / 8);
+
t3_write_reg(adap, A_XGM_RXFIFO_CFG + mac->offset, v);
/* Adjust the TX FIFO threshold based on the MTU */
@@ -329,7 +386,6 @@ int t3_mac_set_mtu(struct cmac *mac, uns
(hwm - lwm) * 4 / 8);
t3_write_reg(adap, A_XGM_TX_PAUSE_QUANTA + mac->offset,
MAC_RXFIFO_SIZE * 4 * 8 / 512);
-
return 0;
}
@@ -357,6 +413,15 @@ int t3_mac_set_speed_duplex_fc(struct cm
V_PORTSPEED(M_PORTSPEED), val);
}
+ val = t3_read_reg(adap, A_XGM_RXFIFO_CFG + oft);
+ val &= ~V_RXFIFOPAUSEHWM(M_RXFIFOPAUSEHWM);
+ if (fc & PAUSE_TX)
+ val |= V_RXFIFOPAUSEHWM(rx_fifo_hwm(
+ t3_read_reg(adap,
+ A_XGM_RX_MAX_PKT_SIZE
+ + oft)) / 8);
+ t3_write_reg(adap, A_XGM_RXFIFO_CFG + oft, val);
+
[PATCH 6/7] cxgb3 - MAC watchdog update
From: Divy Le Ray <[EMAIL PROTECTED]>
Fix variables initialization and usage in the MAC watchdog.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/xgmac.c | 31 +--
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net/cxgb3/xgmac.c
index 16cadba..b261be1 100644
--- a/drivers/net/cxgb3/xgmac.c
+++ b/drivers/net/cxgb3/xgmac.c
@@ -501,6 +501,10 @@ int t3b2_mac_watchdog_task(struct cmac *
unsigned int rx_xcnt;
int status;
+ status = 0;
+ tx_xcnt = 1;/* By default tx_xcnt is making progress */
+ tx_tcnt = mac->tx_tcnt; /* If tx_mcnt is progressing ignore tx_tcnt */
+ rx_xcnt = 1;/* By default rx_xcnt is making progress */
if (tx_mcnt == mac->tx_mcnt) {
tx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_TX_SPI4_SOP_EOP_CNT +
@@ -511,37 +515,44 @@ int t3b2_mac_watchdog_task(struct cmac *
tx_tcnt = (G_TXDROPCNTCH0RCVD(t3_read_reg(adap,
A_TP_PIO_DATA)));
} else {
- mac->toggle_cnt = 0;
- return 0;
+ goto rxcheck;
}
} else {
mac->toggle_cnt = 0;
- return 0;
+ goto rxcheck;
}
if (((tx_tcnt != mac->tx_tcnt) &&
(tx_xcnt == 0) && (mac->tx_xcnt == 0)) ||
((mac->tx_mcnt == tx_mcnt) &&
(tx_xcnt != 0) && (mac->tx_xcnt != 0))) {
- if (mac->toggle_cnt > 4)
+ if (mac->toggle_cnt > 4) {
status = 2;
- else
+ goto out;
+ } else {
status = 1;
+ goto out;
+ }
} else {
mac->toggle_cnt = 0;
- return 0;
+ goto rxcheck;
}
+rxcheck:
if (rx_mcnt != mac->rx_mcnt)
rx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_RX_SPI4_SOP_EOP_CNT +
mac->offset)));
- else
- return 0;
+ else
+ goto out;
- if (mac->rx_mcnt != s->rx_frames && rx_xcnt == 0 && mac->rx_xcnt == 0)
+ if (mac->rx_mcnt != s->rx_frames && rx_xcnt == 0 &&
+ mac->rx_xcnt == 0) {
status = 2;
-
+ goto out;
+ }
+
+out:
mac->tx_tcnt = tx_tcnt;
mac->tx_xcnt = tx_xcnt;
mac->tx_mcnt = s->tx_frames;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] cxgb3 - TP SRAM update
From: Divy Le Ray <[EMAIL PROTECTED]>
The chip executes microcode present in internal RAM,
whose content is loaded from EEPROM on power cycle.
This patch allows an update of the microcode through PIO
without forcing a power cycle.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h | 28 +
drivers/net/cxgb3/cxgb3_main.c | 43
drivers/net/cxgb3/regs.h |7 +++
drivers/net/cxgb3/t3_hw.c | 85
4 files changed, 163 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 8d13796..1637800 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -101,6 +101,7 @@ enum {
TCB_SIZE = 128, /* TCB size */
NMTUS = 16, /* size of MTU table */
NCCTRL_WIN = 32,/* # of congestion control windows */
+ PROTO_SRAM_LINES = 128, /* size of TP sram */
};
#define MAX_RX_COALESCING_LEN 16224U
@@ -124,6 +125,30 @@ enum { /* adapter
interrupt-maintaine
};
enum {
+ TP_VERSION_MAJOR= 1,
+ TP_VERSION_MINOR= 0,
+ TP_VERSION_MICRO= 44
+};
+
+#define S_TP_VERSION_MAJOR 16
+#define M_TP_VERSION_MAJOR 0xFF
+#define V_TP_VERSION_MAJOR(x) ((x) << S_TP_VERSION_MAJOR)
+#define G_TP_VERSION_MAJOR(x) \
+ (((x) >> S_TP_VERSION_MAJOR) & M_TP_VERSION_MAJOR)
+
+#define S_TP_VERSION_MINOR 8
+#define M_TP_VERSION_MINOR 0xFF
+#define V_TP_VERSION_MINOR(x) ((x) << S_TP_VERSION_MINOR)
+#define G_TP_VERSION_MINOR(x) \
+ (((x) >> S_TP_VERSION_MINOR) & M_TP_VERSION_MINOR)
+
+#define S_TP_VERSION_MICRO 0
+#define M_TP_VERSION_MICRO 0xFF
+#define V_TP_VERSION_MICRO(x) ((x) << S_TP_VERSION_MICRO)
+#define G_TP_VERSION_MICRO(x) \
+ (((x) >> S_TP_VERSION_MICRO) & M_TP_VERSION_MICRO)
+
+enum {
SGE_QSETS = 8, /* # of SGE Tx/Rx/RspQ sets */
SGE_RXQ_PER_SET = 2,/* # of Rx queues per set */
SGE_TXQ_PER_SET = 3 /* # of Tx queues per set */
@@ -654,6 +679,9 @@ const struct adapter_info *t3_get_adapte
int t3_seeprom_read(struct adapter *adapter, u32 addr, u32 *data);
int t3_seeprom_write(struct adapter *adapter, u32 addr, u32 data);
int t3_seeprom_wp(struct adapter *adapter, int enable);
+int t3_check_tpsram_version(struct adapter *adapter);
+int t3_check_tpsram(struct adapter *adapter, u8 *tp_ram, unsigned int size);
+int t3_set_proto_sram(struct adapter *adap, u8 *data);
int t3_read_flash(struct adapter *adapter, unsigned int addr,
unsigned int nwords, u32 *data, int byte_oriented);
int t3_load_fw(struct adapter *adapter, const u8 * fw_data, unsigned int size);
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index e0ef724..70ba719 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2089,6 +2089,42 @@ static void cxgb_netpoll(struct net_devi
}
#endif
+#define TPSRAM_NAME "t3%c_protocol_sram-%d.%d.%d.bin"
+int update_tpsram(struct adapter *adap)
+{
+ const struct firmware *tpsram;
+ char buf[64];
+ struct device *dev = >pdev->dev;
+ int ret;
+ char rev;
+
+ rev = adap->params.rev == T3_REV_B2 ? 'b' : 'a';
+
+ snprintf(buf, sizeof(buf), TPSRAM_NAME, rev,
+TP_VERSION_MAJOR, TP_VERSION_MINOR, TP_VERSION_MICRO);
+
+ ret = request_firmware(, buf, dev);
+ if (ret < 0) {
+ dev_err(dev, "could not load TP SRAM: unable to load %s\n",
+ buf);
+ return ret;
+ }
+
+ ret = t3_check_tpsram(adap, tpsram->data, tpsram->size);
+ if (ret)
+ goto release_tpsram;
+
+ ret = t3_set_proto_sram(adap, tpsram->data);
+ if (ret)
+ dev_err(dev, "loading protocol SRAM failed\n");
+
+release_tpsram:
+ release_firmware(tpsram);
+
+ return ret;
+}
+
+
/*
* Periodic accumulation of MAC statistics.
*/
@@ -2439,6 +2475,13 @@ static int __devinit init_one(struct pci
goto out_free_dev;
}
+ err = t3_check_tpsram_version(adapter);
+ if (err == -EINVAL)
+ err = update_tpsram(adapter);
+
+ if (err)
+ goto out_free_dev;
+
/*
* The card is now ready to go. If any errors occur during device
* registration we do not fail the whole card but rather proceed only
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index 02f8731..aa80313 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1218,6 +1218,13 @@
#define A_TP_PROXY_FLOW_CNTL 0x4b0
+#define A_TP_EMBED_OP_FIELD0 0x4e8
+#define A_TP_EMBED_OP_FIELD1 0x4ec
+#define A_TP_EMBED_OP_FIELD2
[PATCH 2/7] cxgb3 - fix netpoll hanlder
From: Divy Le Ray <[EMAIL PROTECTED]>
Fix netpoll handler to work with line interrupt, msi and msi-x.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 12 +---
drivers/net/cxgb3/sge.c|1 -
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 67b4b21..e0ef724 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2076,10 +2076,16 @@ static void vlan_rx_kill_vid(struct net_
static void cxgb_netpoll(struct net_device *dev)
{
struct adapter *adapter = dev->priv;
- struct sge_qset *qs = dev2qset(dev);
+ struct port_info *pi = netdev_priv(dev);
+ int qidx;
- t3_intr_handler(adapter, qs->rspq.polling) (adapter->pdev->irq,
- adapter);
+ for (qidx = pi->first_qset; qidx < pi->first_qset + pi->nqsets; qidx++)
{
+ struct sge_qset *qs = >sge.qs[qidx];
+
+ t3_intr_handler(adapter, qs->rspq.polling) (0,
+ (adapter->flags & USING_MSIX) ?
+ (void *)qs : (void *)adapter);
+ }
}
#endif
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 8dd5b1e..a2cfd68 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -2228,7 +2228,6 @@ irqreturn_t t3_sge_intr_msix_napi(int ir
struct sge_rspq *q = >rspq;
spin_lock(>lock);
- BUG_ON(napi_is_scheduled(qs->netdev));
if (handle_responses(adap, q) < 0)
q->unhandled_irqs++;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] cxgb3 - Fix direct XAUI support
From: Divy Le Ray <[EMAIL PROTECTED]>
Check all lanes for link status on direct XAUI cards.
Don't assume that direct XAUI always uses XGMAC 1.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/ael1002.c | 10 --
drivers/net/cxgb3/regs.h|2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
index 73a41e6..ee140e6 100644
--- a/drivers/net/cxgb3/ael1002.c
+++ b/drivers/net/cxgb3/ael1002.c
@@ -219,7 +219,13 @@ static int xaui_direct_get_link_status(s
unsigned int status;
status = t3_read_reg(phy->adapter,
-XGM_REG(A_XGM_SERDES_STAT0, phy->addr));
+XGM_REG(A_XGM_SERDES_STAT0, phy->addr)) |
+ t3_read_reg(phy->adapter,
+ XGM_REG(A_XGM_SERDES_STAT1, phy->addr)) |
+ t3_read_reg(phy->adapter,
+ XGM_REG(A_XGM_SERDES_STAT2, phy->addr)) |
+ t3_read_reg(phy->adapter,
+ XGM_REG(A_XGM_SERDES_STAT3, phy->addr));
*link_ok = !(status & F_LOWSIG0);
}
if (speed)
@@ -247,5 +253,5 @@ static struct cphy_ops xaui_direct_ops =
void t3_xaui_direct_phy_prep(struct cphy *phy, struct adapter *adapter,
int phy_addr, const struct mdio_ops *mdio_ops)
{
- cphy_init(phy, adapter, 1, _direct_ops, mdio_ops);
+ cphy_init(phy, adapter, phy_addr, _direct_ops, mdio_ops);
}
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index e5a5534..bf9d6be 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -2128,6 +2128,8 @@
#define F_RESETPLL01V_RESETPLL01(1U)
#define A_XGM_SERDES_STAT0 0x8f0
+#define A_XGM_SERDES_STAT1 0x8f4
+#define A_XGM_SERDES_STAT2 0x8f8
#define S_LOWSIG00
#define V_LOWSIG0(x) ((x) << S_LOWSIG0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] cxgb3 - Update FW to 4.1
From: Divy Le Ray <[EMAIL PROTECTED]>
Bump FW version to 4.1.
Modify chip tuning in consequence.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/regs.h|4
drivers/net/cxgb3/t3_hw.c | 42 +++---
drivers/net/cxgb3/version.h |2 +-
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index bf9d6be..2c47d4a 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1160,6 +1160,8 @@
#define A_TP_MOD_CHANNEL_WEIGHT 0x434
+#define A_TP_MOD_RATE_LIMIT 0x438
+
#define A_TP_PIO_ADDR 0x440
#define A_TP_PIO_DATA 0x444
@@ -1214,6 +1216,8 @@
#define G_TXDROPCNTCH0RCVD(x) (((x) >> S_TXDROPCNTCH0RCVD) & \
M_TXDROPCNTCH0RCVD)
+#define A_TP_PROXY_FLOW_CNTL 0x4b0
+
#define A_ULPRX_CTL 0x500
#define S_ROUND_ROBIN4
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index fb485d0..9e3591d 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -921,7 +921,7 @@ static int t3_flash_erase_sectors(struct
/*
* t3_load_fw - download firmware
* @adapter: the adapter
- * @fw_data: the firrware image to write
+ * @fw_data: the firmware image to write
* @size: image size
*
* Write the supplied firmware image to the card's serial flash.
@@ -2362,7 +2362,7 @@ static void tp_config(struct adapter *ad
F_TCPCHECKSUMOFFLOAD | V_IPTTL(64));
t3_write_reg(adap, A_TP_TCP_OPTIONS, V_MTUDEFAULT(576) |
F_MTUENABLE | V_WINDOWSCALEMODE(1) |
-V_TIMESTAMPSMODE(1) | V_SACKMODE(1) | V_SACKRX(1));
+V_TIMESTAMPSMODE(0) | V_SACKMODE(1) | V_SACKRX(1));
t3_write_reg(adap, A_TP_DACK_CONFIG, V_AUTOSTATE3(1) |
V_AUTOSTATE2(1) | V_AUTOSTATE1(0) |
V_BYTETHRESHOLD(16384) | V_MSSTHRESHOLD(2) |
@@ -2371,16 +2371,18 @@ static void tp_config(struct adapter *ad
F_IPV6ENABLE | F_NICMODE);
t3_write_reg(adap, A_TP_TX_RESOURCE_LIMIT, 0x18141814);
t3_write_reg(adap, A_TP_PARA_REG4, 0x5050105);
- t3_set_reg_field(adap, A_TP_PARA_REG6,
-adap->params.rev > 0 ? F_ENABLEESND : F_T3A_ENABLEESND,
-0);
+ t3_set_reg_field(adap, A_TP_PARA_REG6, 0,
+adap->params.rev > 0 ? F_ENABLEESND :
+F_T3A_ENABLEESND);
t3_set_reg_field(adap, A_TP_PC_CONFIG,
-F_ENABLEEPCMDAFULL | F_ENABLEOCSPIFULL,
-F_TXDEFERENABLE | F_HEARBEATDACK | F_TXCONGESTIONMODE |
-F_RXCONGESTIONMODE);
+F_ENABLEEPCMDAFULL,
+F_ENABLEOCSPIFULL |F_TXDEFERENABLE | F_HEARBEATDACK |
+F_TXCONGESTIONMODE | F_RXCONGESTIONMODE);
t3_set_reg_field(adap, A_TP_PC_CONFIG2, F_CHDRAFULL, 0);
-
+ t3_write_reg(adap, A_TP_PROXY_FLOW_CNTL, 1080);
+ t3_write_reg(adap, A_TP_PROXY_FLOW_CNTL, 1000);
+
if (adap->params.rev > 0) {
tp_wr_indirect(adap, A_TP_EGRESS_CONFIG, F_REWRITEFORCETOSIZE);
t3_set_reg_field(adap, A_TP_PARA_REG3, F_TXPACEAUTO,
@@ -2390,9 +2392,10 @@ static void tp_config(struct adapter *ad
} else
t3_set_reg_field(adap, A_TP_PARA_REG3, 0, F_TXPACEFIXED);
- t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT1, 0x12121212);
- t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT0, 0x12121212);
- t3_write_reg(adap, A_TP_MOD_CHANNEL_WEIGHT, 0x1212);
+ t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT1, 0);
+ t3_write_reg(adap, A_TP_TX_MOD_QUEUE_WEIGHT0, 0);
+ t3_write_reg(adap, A_TP_MOD_CHANNEL_WEIGHT, 0);
+ t3_write_reg(adap, A_TP_MOD_RATE_LIMIT, 0xf220);
}
/* Desired TP timer resolution in usec */
@@ -2468,6 +2471,7 @@ int t3_tp_set_coalescing_size(struct ada
val |= F_RXCOALESCEENABLE;
if (psh)
val |= F_RXCOALESCEPSHEN;
+ size = min(MAX_RX_COALESCING_LEN, size);
t3_write_reg(adap, A_TP_PARA_REG2, V_RXCOALESCESIZE(size) |
V_MAXRXDATA(MAX_RX_COALESCING_LEN));
}
@@ -2496,11 +2500,11 @@ static void __devinit init_mtus(unsigned
* it can accomodate max size TCP/IP headers when SACK and timestamps
* are enabled and still have at least 8 bytes of payload.
*/
- mtus[0] = 88;
- mtus[1] = 256;
- mtus[2] = 512;
- mtus[3] = 576;
- mtus[4] = 808;
+ mtus[1] = 88;
+ mtus[1] = 88;
+ mtus[2] = 256;
+ mtus[3] = 512;
+ mtus[4] = 576;
mtus[5] = 1024;
mtus[6] = 1280;
mtus[7] = 1492;
@@ -2802,7 +2806,7 @@ static void init_hw_for_avail_ports(stru
t3_set_reg_field(adap, A_ULPTX_CONFIG,
[PATCH 1/7] cxgb3 - Fix SGE page management
From: Divy Le Ray <[EMAIL PROTECTED]>
Streamline page management on RX.
Fix dma mappings.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h | 38 ++--
drivers/net/cxgb3/sge.c | 425 ++-
2 files changed, 233 insertions(+), 230 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
index 80c3d8f..ab72563 100644
--- a/drivers/net/cxgb3/adapter.h
+++ b/drivers/net/cxgb3/adapter.h
@@ -71,27 +71,29 @@ enum { /* adapter flags */
QUEUES_BOUND = (1 << 3),
};
+struct fl_pg_chunk {
+ struct page *page;
+ void *va;
+ unsigned int offset;
+};
+
struct rx_desc;
struct rx_sw_desc;
-struct sge_fl_page {
- struct skb_frag_struct frag;
- unsigned char *va;
-};
-
-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 */
- unsigned int cntxt_id; /* SGE context id for the free list */
- struct sge_fl_page page;
- 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 long empty;/* # of times queue ran out of buffers */
+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 fl_pg_chunk pg_chunk;/* page chunk cache */
+ unsigned int use_pages; /* whether FL uses pages or sk_buffs */
+ 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 */
unsigned long alloc_failed; /* # of times buffer allocation failed */
};
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 3666586..8dd5b1e 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -46,23 +46,16 @@
#define SGE_RX_SM_BUF_SIZE 1536
-/*
- * If USE_RX_PAGE is defined, the small freelist populated with (partial)
- * pages instead of skbs. Pages are carved up into RX_PAGE_SIZE chunks (must
- * be a multiple of the host page size).
- */
-#define USE_RX_PAGE
-#define RX_PAGE_SIZE 2048
-
-/*
- * skb freelist packets are copied into a new skb (and the freelist one is
- * reused) if their len is <=
- */
#define SGE_RX_COPY_THRES 256
+#define SGE_RX_PULL_LEN128
/*
- * Minimum number of freelist entries before we start dropping TUNNEL frames.
+ * Page chunk size for FL0 buffers if FL0 is to be populated with page chunks.
+ * It must be a divisor of PAGE_SIZE. If set to 0 FL0 will use sk_buffs
+ * directly.
*/
+#define FL0_PG_CHUNK_SIZE 2048
+
#define SGE_RX_DROP_THRES 16
/*
@@ -100,12 +93,12 @@ struct tx_sw_desc {/* SW state per Tx
struct sk_buff *skb;
};
-struct rx_sw_desc {/* SW state per Rx descriptor */
+struct rx_sw_desc {/* SW state per Rx descriptor */
union {
struct sk_buff *skb;
- struct sge_fl_page page;
- } t;
-DECLARE_PCI_UNMAP_ADDR(dma_addr);
+ struct fl_pg_chunk pg_chunk;
+ };
+ DECLARE_PCI_UNMAP_ADDR(dma_addr);
};
struct rsp_desc { /* response queue descriptor */
@@ -351,27 +344,26 @@ static void free_rx_bufs(struct pci_dev
pci_unmap_single(pdev, pci_unmap_addr(d, dma_addr),
q->buf_size, PCI_DMA_FROMDEVICE);
-
- if (q->buf_size != RX_PAGE_SIZE) {
- kfree_skb(d->t.skb);
- d->t.skb = NULL;
+ if (q->use_pages) {
+ put_page(d->pg_chunk.page);
+ d->pg_chunk.page = NULL;
} else {
- if (d->t.page.frag.page)
- put_page(d->t.page.frag.page);
- d->t.page.frag.page = NULL;
+ kfree_skb(d->skb);
+ d->skb = NULL;
[PATCH 2.6.22 0/7] cxgb3 - bug fixes
Hi Jeff, I'm submitting a set of bug fixes for inclusion in 2.6.22. The patches are built against Linus'git tree. Here is a brief description: - Fix page management in the SGE code, - Fix netpoll handler, - Fix link status detection for direct XAUI adapters, - Update FW to 4.1 and proceed to subsequent HW tuning, - Work around potential hang on MTU change, - Fix MAC watchdog, - Allow microcode update without a power cycle. Cheers, Divy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote: > On Friday 25 May 2007 21:06, Casey Schaufler wrote: > > --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote: > > > ... > > > Well, my point was exactly that App Armor doesn't (as far as I know) do > > > anything to enforce the argv[0] convention, > > > > Sounds like an opportunity for improvement then. > > Jeez, what argv[0] convention are you both talking about? >From the exec(3) man page: "The first argument, by convention, should point to the file name associated with the file being executed." since the man page calls it a convention, so do I. > argv[0] is not guaranteed to have any association with the > name of the executable. Feel free to have any discussion > about argv[0] you want, but *please* keep it away from > AppArmor, which really has nothing to do with it. As I pointed out, if you wanted to trust the argv[0] value (which I understand AppArmor makes no claims about) and you wanted to use the argv[0] value to determine application behavior (which several people claim is a Bad Idea) you could use Name Based Access Control to provide different access to the common binary. As I pointed out before, that's a lot of "if's". > It would be nice if you could stop calling argv[0] checks ``name-based access > > control'': from the point of view of the kernel no access control is > involved, and even application-level argv[0] based access control makes no > sense whatsoever. Fair enough, I don't believe that an argv[0] check ought to be used as a security mechanism. I am not convinced that everyone would agree with us. Casey Schaufler [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: PCIE
David Miller wrote: > From: Manu Abraham <[EMAIL PROTECTED]> > Date: Sat, 26 May 2007 19:03:12 +0400 > >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. > > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. > Ok, that explains it a bit, but i am pulling out a bit of hair on the other aspects i wrote in this thread, of course i am a bit new to PCIe and hence all my questions/doubts. Hope someone can clear them. Thanks, Manu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCIE
From: Manu Abraham <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 19:03:12 +0400 > i presume then i shouldn't be using IRQF_SHARED, if using MSI. That's actually a really good question. It is likely architecture dependant whether the PCI controller wires unique MSI interrupts to shared cpu interrupt lines. I can imagine many systems where the cpu simply doesn't have enough interrupt pins to uniquely identify every possible MSI interrupt source. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.21.1] resume doesn't run suspended kernel?
I was testing susp2disk in 2.6.21.1 under FC6, to support reliable computing environment (RCE) needs. The idea is that if power fails, after some short time on UPS the system does susp2disk with a time set, and boots back every so often to see if power is stable. No, I don't want susp2mem until I debug it, console come up in useless mode, console as kalidescope is not what I need. Anyway, I pulled the plug on the UPS, and the system shut down. But when it powered up, it booted the default kernel rather than the test kernel, decided that it couldn't resume, and then did a cold boot. I can bypass this by making the debug kernel the default, but WHY? Is the kernel not saved such that any kernel can be rolled back into memory and run? Actually, the answer is HELL NO, so I really ask if this is the intended mode of operation, that only the default boot kernel will restore. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
From: Uwe Bugla <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 12:40:54 +0200 > Am Samstag, 26. Mai 2007 07:00 schrieben Sie: > > Try it again, please. > > NO! Your not a nice person, and consistently so, therefore you can't post to the mailing lists I run any more. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [condingstyle] Add chapter on tests
On 5/26/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: Based in part on Auke's patch. Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> --- Documentation/CodingStyle | 74 +++--- 1 file changed, 64 insertions(+), 10 deletions(-) Index: linux-2.6.22-rc3/Documentation/CodingStyle === --- linux-2.6.22-rc3.orig/Documentation/CodingStyle +++ linux-2.6.22-rc3/Documentation/CodingStyle @@ -407,7 +407,61 @@ out: return result; } - Chapter 8: Commenting + Chapyer 8: Tests --- Fix the "Chapyer" spelling above. However, I think this set of rules is not universally agreed to and probably should not be added at this time. I'm not convinced that it makes the code more readable. scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
Am Samstag 26 Mai 2007 schrieb Rafael J. Wysocki: Hi Rafael! > The outcome was, more-or-less, that we'll work on merging suspend2 or > at least some parts of it. > > However, in the meantime there have been some discussions implying that > we have some important problems with suspend/hibernation that suspend2 > doesn't solve and that IMHO are more urgent than the merging of > suspend2 right not. > > So, as far as I'm concerned, the plan is to fix the more urgent > problems first and to work on merging suspend2 as far as there's time > to do this. > > The problem is there are only a few people working on it and there's a > lot to do, so I can only ask you to be patient. ;-) Thats fine with me - I understand that. I just thought that there has been no outcome at all. I will try to be patient as long as I do not dig into kernel hacking myself deeply enough to be able to help with that - did not do more than to put together two conflicting patches to compile my own kernels till now and forward port a patch for a sundance network card. I can help with testing once there is something testable tough. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 23:52 schrieben Sie:
> On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > > Uwe, please try the following patch:
> > > > >
> > > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > > ===
> > > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> > > > > 18:09:50.0 +0200 +++
> > > > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit
> > > > > b44_init_one(struct printk("%2.2x%c", dev->dev_addr[i],
> > > > > i == 5 ? '\n' : ':');
> > > > >
> > > > > +#if 0
> > > > > /* Initialize phy */
> > > > > spin_lock_irq(>lock);
> > > > > b44_chip_reset(bp);
> > > > > spin_unlock_irq(>lock);
> > > > > +#endif
> > > > >
> > > > > return 0;
> > > >
> > > > Against what kernel please?
> > > > Just try to be a bit more eloquent, man!
> > >
> > > Against a kernel which does not work for you, of course.
> > >
> > > Sometimes I wonder... (no better not say that).
> >
> > YES! And I wonder TOO, definitely!
> >
> > Quand meme (now, if you do not speak french: Above all that), I applied
> > your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to
> > get your "dream" being fulfilled!
> >
> > Result is: No change!
> > Non-functionable b44-device at all!
> >
> > Hint: Although being a "non-hacker" or "non-developer" I do have stepped
> > across some experienced developer people who at least added some code to
> > make their modules function in the following way:
> >
> > modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or
> > debug=6)
> >
> > In so far, if you continue to state that debugging is nothing but
> > guessing around wildly you are definitely wrong, showing us all your
> > missing code hacker experience. If you DO continue like this every step
> > will be a torture not only for me but for the reading folks as well.
> >
> > But every human being is here to learn and develop: In so far I am very
> > optimistic!
> >
> > Apart from the Kconfig chaos that seems to be subordinate in your
> > personal rating scale, you at least could have added some functions like
> > the above mentioned functions.
> >
> > The fact that you simply ignored to imply those functions and continue to
> > call other people dumb shows exactly how small and humble you are.
> >
> > Apart from that:
> > The message that you rooted to my place was no "proof" at all for any
> > kind of disfunctionality or compatibility issue!
> >
> > In that message the lack of performance of the "enclosed" or "old"
> > or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the
> > one ripped by you personally into two modules called b44 and ssb.
> >
> > In so far I would deeply appreciate you personally to stick to the facts
> > in your personal lack of knowledge about the b44 driver instead of
> > playing bad politics against other people like me and others.
> >
> >
> > Hello my dear Andrew Morton,
> >
> > Could you please do me and the rest of the world two favours?
> >
> > A. Rip Michael Buesches code out of the mm-tree
> >
> > B. Give Michael Buesch a fair chance to revise his disfunctionable code
> > outside the mm-tree and / or the vanilla mainline.
> >
> > Side note for the what and why:
> >
> > I like to help avoid dangers by testing the mm-tree.
> > BUT:
> >
> > If real debugging conforms to nothing but guessing around wildly let me
> > tell you that I do not appreciate to be part of that torture due to the
> > lack of experience of some German spare time hacker.
> >
> > A: proven by facts not knowing or even wanting to know how to imply
> > appropriate functionable debug parametres in his driver code
> >
> > B: non-cooperative as far as Kconfig help features are concerned (i. E.
> > help to understand the issues for users
> >
> > C: calling all people simply dumb who do not know about his personal
> > issues at all
> >
> > Thank you, Andrew Morton! You are real fine!
>
> Everyone just needs to cool down. And you both (Uwe and Michael) just
> need to try debugging the problem.
>
> Abstracting the SSB code into a library is clearly the correct solution,
> rather than having the same code in two separate places. The whole
> _point_ of having code in various trees (wireless, mm, etc) is to find
> these bugs before the patches hit mainline. Even testing on > 3
> machines may not uncover subtle bugs (for example, different behavior on
> different silicon revisions, especially in reverse-engineered parts),
> it's only something Michael can test so far before other people have to
> pick it up and test it. And that's where you come in, Uwe.
>
> So both of you should actually just stop the name-calling, suck
Re: [patch 6/7] ps3: ROM Storage Driver
On Sat, 2007-05-26 at 10:52 +0200, Geert Uytterhoeven wrote: > On Sat, 26 May 2007, Benjamin Herrenschmidt wrote: > > On Fri, 2007-05-25 at 13:24 +0200, Olaf Hering wrote: > > > On Fri, May 25, [EMAIL PROTECTED] wrote: > > > > > > > +++ b/drivers/scsi/ps3rom.c > > > > > > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0); > > > > > > linux/highmem.h is not included to get the kmap_* prototypes. > > > > Beside, I don't see the point of using kmap on ppc64... > > So what should I use instead? you don't need to map ... the linear mapping is there page_address() should just work. But then, kmap will resolve to just that anyway so I suppose it doesn't matter. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/7] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
On Sat, 2007-05-26 at 10:51 +0200, Geert Uytterhoeven wrote: > > I know. > > Do you know another way to allocate an aligned chunk of 256 KiB of > physically > contiguous memory, possibly a long time after boot up? kmalloc & a good prayer ? :-0 Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default
Hi, Following the "Freezing of kernel threads" discussion (http://lkml.org/lkml/2007/5/12/162) I have created a patch that changes the freezer's behavior with respect to kernel threads. Namely, with the patch applied all kernel threads are nonfreezable by default (have PF_NOFREEZE set) and the ones that want to be frozen need to call set_freezable() (which clears PF_NOFREEZE for them) and try_to_freeze(). The other (nonfreezable) kernel threads don't need to call try_to_freeze() any more. I have removed try_to_freeze() from a handful of kernel threads that I think need not be freezable, but in many cases I wasn't quite sure whether or not it was a good idea to change the current behavior. For this reason I've added set_freezable() to the majority of (currently freezable) kernel threads that belong to device drivers and filesystems. Of course, I have removed the setting of PF_NOFREEZE from the kernel threads that are currently nonfreezable, since with the other changes in the patch it isn't necessary any more. This patch is on top of the "Freezer: Avoid freezing kernel threads prematurely" patch that I posted yestarday, available at http://lkml.org/lkml/2007/5/25/199 (updated version that applies cleanly on top of 2.6.22-rc3, is available at http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/07-freezer-avoid-freezing-kernel-threads-prematurely.patch). It has been tested on a couple of machines and doesn't seem to break anything. [As you can see there are quite a lot of files affected, so I didn't add all maintainers of them to the CC list. In fact, I'm not sure how to handle notifying them of the change, so please advise.] Greetings, Rafael Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> --- Documentation/power/kernel_threads.txt| 54 -- Documentation/power/swsusp.txt| 16 arch/i386/kernel/apm.c|1 arch/i386/kernel/io_apic.c|1 drivers/block/loop.c |7 --- drivers/block/pktcdvd.c |3 - drivers/char/apm-emulation.c | 11 -- drivers/char/hvc_console.c|1 drivers/edac/edac_mc.c|1 drivers/ieee1394/ieee1394_core.c |2 - drivers/ieee1394/nodemgr.c|1 drivers/input/gameport/gameport.c |1 drivers/input/serio/serio.c |1 drivers/input/touchscreen/ucb1400_ts.c|1 drivers/macintosh/therm_adt746x.c |1 drivers/macintosh/windfarm_core.c |4 +- drivers/md/md.c |1 drivers/media/dvb/dvb-core/dvb_frontend.c |1 drivers/media/video/cx88/cx88-tvaudio.c |1 drivers/media/video/msp3400-kthreads.c|5 +- drivers/media/video/tvaudio.c |2 - drivers/media/video/video-buf-dvb.c |1 drivers/media/video/vivi.c|1 drivers/mfd/ucb1x00-ts.c |1 drivers/mmc/card/queue.c |6 --- drivers/mtd/mtd_blkdevs.c |2 - drivers/mtd/ubi/wl.c |1 drivers/net/wireless/airo.c |3 + drivers/net/wireless/libertas/main.c |1 drivers/pcmcia/cs.c |1 drivers/pnp/pnpbios/core.c|1 drivers/scsi/libsas/sas_scsi_host.c |2 - drivers/scsi/scsi_error.c |2 - drivers/usb/atm/ueagle-atm.c |1 drivers/usb/core/hub.c|1 drivers/usb/gadget/file_storage.c |2 + drivers/usb/storage/usb.c |5 -- drivers/video/ps3fb.c |1 drivers/w1/w1.c |1 fs/cifs/cifsfs.c |1 fs/cifs/connect.c |1 fs/jffs2/background.c |1 fs/lockd/clntproc.c |1 fs/xfs/linux-2.6/xfs_super.c |1 include/linux/freezer.h |9 + init/do_mounts_initrd.c |7 +-- kernel/audit.c|4 -- kernel/exit.c |5 ++ kernel/fork.c |2 - kernel/rcutorture.c |3 - kernel/rtmutex-tester.c |1 kernel/sched.c|3 - kernel/softirq.c |1 kernel/softlockup.c |1 kernel/workqueue.c|4 +- mm/pdflush.c |4 -- mm/vmscan.c |9 - net/bluetooth/bnep/core.c |1 net/bluetooth/cmtp/core.c |1 net/bluetooth/hidp/core.c |1 net/bluetooth/rfcomm/core.c |1 net/core/pktgen.c |
Re: Kernel bug at net/core/skbuf.c:93 [fixed in 2.6.21.2]
Michal, thanks! Using 2.6.21.3 cured the problem. The fix was mentioned in the changelog of 2.6.21.2 Uli -- Ulrich Mayer Michal Piotrowski schrieb: Hi Ulrich, On 26/05/07, Ulrich Mayer <[EMAIL PROTECTED]> wrote: A couple of days ago I sent a note to Ingo Molnar with the following bug report. His response was: > hm - this doesnt seem to be an apic problem, more of a VDR problem. > Could you send this report to [EMAIL PROTECTED] > > Ingo Uli -- Ulrich Mayer It looks like a bug in sis900 driver. Please try the latest -stable. Regards, Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [INPUT] i8042 not detecting AUX port
Hi, > > On Thursday 24 May 2007 16:50, Emmanuel Fusté wrote: > > > This bios is full of bugs, a real plague. Will try to quirk > > > this register at boot time. I tried, but it did not change the behavior of the loop command. Will stick with i8042.noloop as boot parameter. Thank you for your time. > > > > > > > There isn't an updated BIOS, is there? > > > No update, the latest one was from 1997. I tried in 2003 to > get a update from esupport.com but they never give me a bios > which boot the machine. This computer was a ephemeral beast > (dual P5mmx). > Best regards, Emmanuel. --- Créez votre adresse électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[stable][PATCH] pci: quirk disable MSI on via vt3351
The Via VT3351 APIC does not play well with MSI and unleashes a flood of APIC errors when MSI is used to deliver interrupts. The problem was recently exposed when the atl1 network device driver, which enables MSI by default, stimulated APIC errors on an Asus M2V mainboard, which employs the Via VT3351. See http://bugzilla.kernel.org/show_bug.cgi?id=8472 for additional details on this bug. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|1 + include/linux/pci_ids.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 5af9125..e2d81af 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1751,6 +1751,7 @@ static void __init quirk_disable_all_msi(struct pci_dev *dev) DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_GCNB_LE, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS400_200, quirk_disable_all_msi); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS480, quirk_disable_all_msi); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_VT3351, quirk_disable_all_msi); /* Disable MSI on chipsets that are known to not support it */ static void __devinit quirk_disable_msi(struct pci_dev *dev) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 600308f..2a0a70d 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -1287,6 +1287,7 @@ #define PCI_DEVICE_ID_VIA_P4M800CE 0x0314 #define PCI_DEVICE_ID_VIA_P4M890 0x0327 #define PCI_DEVICE_ID_VIA_VT3336 0x0336 +#define PCI_DEVICE_ID_VIA_VT3351 0x0351 #define PCI_DEVICE_ID_VIA_8371_0 0x0391 #define PCI_DEVICE_ID_VIA_8501_0 0x0501 #define PCI_DEVICE_ID_VIA_82C561 0x0561 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Saturday 26 May 2007 23:32:50 Uwe Bugla wrote: > Hint: Although being a "non-hacker" or "non-developer" I do have stepped ... > In so far, if you continue to state that debugging is nothing but guessing > around wildly you are definitely wrong, showing us all your missing code > hacker experience. If you DO continue like this every step will be a torture > not only for me but for the reading folks as well. You REALLY want to tell me, a developer and maintainer of several big projects, how debugging is done, being a non-developer and non-hacker? I can't believe what I am reading here. > The fact that you simply ignored to imply those functions and continue to > call > other people dumb shows exactly how small and humble you are. Please quote me where I called someone dumb. Ah, yes. I am inhuman and whatever. We know that already. > Apart from that: > The message that you rooted to my place was no "proof" at all for any kind of > disfunctionality or compatibility issue! > > In that message the lack of performance of the "enclosed" or "old" > or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one > ripped by you personally into two modules called b44 and ssb. Ah, no? I think you didn't completely understand the mail. Steve reported a bug in b44 2.6.22. Please note that 2.6.22 does NOT include ssb. But I'm sure you'll find a way to make me responsible for this bug, anyway. b44 is buggy and this is NOT caused by ssb. Re-read steve's mail. > In so far I would deeply appreciate you personally to stick to the facts in > your personal lack of knowledge about the b44 driver instead of playing bad > politics against other people like me and others. Oh, poor poor guy. I lack knowledge about b44? Oh, I suppose that was a typo and you meant yourself. > Hello my dear Andrew Morton, > > Could you please do me and the rest of the world two favours? > > A. Rip Michael Buesches code out of the mm-tree > > B. Give Michael Buesch a fair chance to revise his disfunctionable code > outside the mm-tree and / or the vanilla mainline. Andrew, I see that you are in a bad situation now. I respect every decision you make. But please still consider that b44 works perfectly well for me. I tested it today on _all_ kernels that did not work for Uwe in this thread. On my device (BCM4401-B0) it works on all of these kernels. I'd suggest we leave the code in the -mm tree and wait for someone else to show up with a bugreport. It's simply impossible to debug this problem with the help of Uwe. > C: calling all people simply dumb who do not know about his personal issues > at > all Please quote this, Uwe. > Thank you, Andrew Morton! You are real fine! > > Sincerely > > Uwe > > Uwe, I just added you to my killfile. Don't bother sending mail to me any longer. It will not arrive. I'm not interested in your stupid "bugreports" anymore, as they are useless and consist only of personal insults and personal miscreditations. Welcome to the killfile of yet another kernel developer. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: any value to "NORET_TYPE" macro?
"Robert P. J. Day" <[EMAIL PROTECTED]> writes: > that's not true, AFAICT. the pattern seems to be that, in the case of > declarations, attributes go at the end, as in: Anyway, that attribute has to be in the declarations as without it there the compiler can't optimize the callers. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > Uwe, please try the following patch:
> > > >
> > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > ===
> > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c 2007-05-18
> > > > 18:09:50.0 +0200 +++
> > > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> > > > printk("%2.2x%c", dev->dev_addr[i],
> > > >i == 5 ? '\n' : ':');
> > > >
> > > > +#if 0
> > > > /* Initialize phy */
> > > > spin_lock_irq(>lock);
> > > > b44_chip_reset(bp);
> > > > spin_unlock_irq(>lock);
> > > > +#endif
> > > >
> > > > return 0;
> > >
> > > Against what kernel please?
> > > Just try to be a bit more eloquent, man!
> >
> > Against a kernel which does not work for you, of course.
> >
> > Sometimes I wonder... (no better not say that).
>
> YES! And I wonder TOO, definitely!
>
> Quand meme (now, if you do not speak french: Above all that), I applied your
> patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get
> your "dream" being fulfilled!
>
> Result is: No change!
> Non-functionable b44-device at all!
>
> Hint: Although being a "non-hacker" or "non-developer" I do have stepped
> across some experienced developer people who at least added some code to make
> their modules function in the following way:
>
> modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6)
>
> In so far, if you continue to state that debugging is nothing but guessing
> around wildly you are definitely wrong, showing us all your missing code
> hacker experience. If you DO continue like this every step will be a torture
> not only for me but for the reading folks as well.
>
> But every human being is here to learn and develop: In so far I am very
> optimistic!
>
> Apart from the Kconfig chaos that seems to be subordinate in your personal
> rating scale, you at least could have added some functions like the above
> mentioned functions.
>
> The fact that you simply ignored to imply those functions and continue to
> call
> other people dumb shows exactly how small and humble you are.
>
> Apart from that:
> The message that you rooted to my place was no "proof" at all for any kind of
> disfunctionality or compatibility issue!
>
> In that message the lack of performance of the "enclosed" or "old"
> or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one
> ripped by you personally into two modules called b44 and ssb.
>
> In so far I would deeply appreciate you personally to stick to the facts in
> your personal lack of knowledge about the b44 driver instead of playing bad
> politics against other people like me and others.
>
>
> Hello my dear Andrew Morton,
>
> Could you please do me and the rest of the world two favours?
>
> A. Rip Michael Buesches code out of the mm-tree
>
> B. Give Michael Buesch a fair chance to revise his disfunctionable code
> outside the mm-tree and / or the vanilla mainline.
>
> Side note for the what and why:
>
> I like to help avoid dangers by testing the mm-tree.
> BUT:
>
> If real debugging conforms to nothing but guessing around wildly let me tell
> you that I do not appreciate to be part of that torture due to the lack of
> experience of some German spare time hacker.
>
> A: proven by facts not knowing or even wanting to know how to imply
> appropriate functionable debug parametres in his driver code
>
> B: non-cooperative as far as Kconfig help features are concerned (i. E. help
> to understand the issues for users
>
> C: calling all people simply dumb who do not know about his personal issues
> at
> all
>
> Thank you, Andrew Morton! You are real fine!
Everyone just needs to cool down. And you both (Uwe and Michael) just
need to try debugging the problem.
Abstracting the SSB code into a library is clearly the correct solution,
rather than having the same code in two separate places. The whole
_point_ of having code in various trees (wireless, mm, etc) is to find
these bugs before the patches hit mainline. Even testing on > 3
machines may not uncover subtle bugs (for example, different behavior on
different silicon revisions, especially in reverse-engineered parts),
it's only something Michael can test so far before other people have to
pick it up and test it. And that's where you come in, Uwe.
So both of you should actually just stop the name-calling, suck it up,
and debug the problem. We're getting nothing done here.
Dan
> Sincerely
>
> Uwe
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [EMAIL PROTECTED]
Re: [PATCH, RFT, v4] sata_mv: convert to new EH
Dave Dillow wrote: On Sat, 2007-05-26 at 16:56 -0400, Jeff Garzik wrote: Dave, any chance you could try 2.6.22-rc3 + my v4 patch, on a different hard drive? Preferably a non-Maxtor, or at least not another Maxtor 6L200S0. If that's a big deal, don't worry about it. I just want to rule out buggy firmware and/or bad hard drive in your case. It is likely I can come up with at least one, and maybe two if I cannibalize my main machine... do you want results under all three kernels or just the v4 patch? Mainly the v4 patch, but an it-works test on 2.6.22-rc3 just for sanity's sake would be useful as well. If you have time, check both new and old drives with SMART smartctl -d ata -t long /dev/blahblah to make sure the extended tests don't find anything wrong. Extended tests usually take 30-90 minutes. You can access the hard drive while the extended test is running, but I/O will be slower for obvious reasons. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > Uwe, please try the following patch:
> > >
> > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > ===
> > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> > > 18:09:50.0 +0200 +++
> > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> > > printk("%2.2x%c", dev->dev_addr[i],
> > > i == 5 ? '\n' : ':');
> > >
> > > +#if 0
> > > /* Initialize phy */
> > > spin_lock_irq(>lock);
> > > b44_chip_reset(bp);
> > > spin_unlock_irq(>lock);
> > > +#endif
> > >
> > > return 0;
> >
> > Against what kernel please?
> > Just try to be a bit more eloquent, man!
>
> Against a kernel which does not work for you, of course.
>
> Sometimes I wonder... (no better not say that).
YES! And I wonder TOO, definitely!
Quand meme (now, if you do not speak french: Above all that), I applied your
patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get
your "dream" being fulfilled!
Result is: No change!
Non-functionable b44-device at all!
Hint: Although being a "non-hacker" or "non-developer" I do have stepped
across some experienced developer people who at least added some code to make
their modules function in the following way:
modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6)
In so far, if you continue to state that debugging is nothing but guessing
around wildly you are definitely wrong, showing us all your missing code
hacker experience. If you DO continue like this every step will be a torture
not only for me but for the reading folks as well.
But every human being is here to learn and develop: In so far I am very
optimistic!
Apart from the Kconfig chaos that seems to be subordinate in your personal
rating scale, you at least could have added some functions like the above
mentioned functions.
The fact that you simply ignored to imply those functions and continue to call
other people dumb shows exactly how small and humble you are.
Apart from that:
The message that you rooted to my place was no "proof" at all for any kind of
disfunctionality or compatibility issue!
In that message the lack of performance of the "enclosed" or "old"
or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one
ripped by you personally into two modules called b44 and ssb.
In so far I would deeply appreciate you personally to stick to the facts in
your personal lack of knowledge about the b44 driver instead of playing bad
politics against other people like me and others.
Hello my dear Andrew Morton,
Could you please do me and the rest of the world two favours?
A. Rip Michael Buesches code out of the mm-tree
B. Give Michael Buesch a fair chance to revise his disfunctionable code
outside the mm-tree and / or the vanilla mainline.
Side note for the what and why:
I like to help avoid dangers by testing the mm-tree.
BUT:
If real debugging conforms to nothing but guessing around wildly let me tell
you that I do not appreciate to be part of that torture due to the lack of
experience of some German spare time hacker.
A: proven by facts not knowing or even wanting to know how to imply
appropriate functionable debug parametres in his driver code
B: non-cooperative as far as Kconfig help features are concerned (i. E. help
to understand the issues for users
C: calling all people simply dumb who do not know about his personal issues at
all
Thank you, Andrew Morton! You are real fine!
Sincerely
Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: software suspend doesn't work with 2.6.22-rc3
Hi. On Sat, 2007-05-26 at 14:49 +0200, Maximilian Engelhardt wrote: > On Saturday 26 May 2007, Nigel Cunningham wrote: > > Hi. > > > > On Sat, 2007-05-26 at 11:28 +0200, Maximilian Engelhardt wrote: > > > Hello, > > > > > > When I try software suspend on my laptop it always returns to my running > > > system after some time. > > > This is what's logged by the kernel: > > > > > > swsusp: Basic memory bitmaps created > > > Stopping tasks ... > > > Stopping kernel threads timed out after 20 seconds (1 tasks refusing to > > > freeze): > > > cryptd > > > Restarting tasks ... done. > > > swsusp: Basic memory bitmaps freed > > > > > > I have no idea what's the problem, but if you tell me what I should do I > > > can create debugging information and/or test patches. > > > > Could you try this patch, please? It should help. > > > > Herbert, is this right? If cryptd is going to be used for block devs, > > the task should probably be PF_NOFREEZE (or whatever it is today) > > instead. > > > > Regards, > > > > Nigel > > > > crypto/cryptd.c |1 + > > include/linux/freezer.h |3 +++ > > kernel/power/process.c |2 +- > > 3 files changed, 5 insertions(+), 1 deletion(-) > > diff -ruNp 991-fix-cryptd.patch-old/crypto/cryptd.c > > 991-fix-cryptd.patch-new/crypto/cryptd.c --- > > 991-fix-cryptd.patch-old/crypto/cryptd.c2007-05-19 18:16:47.0 > > +1000 +++ 991-fix-cryptd.patch-new/crypto/cryptd.c 2007-05-26 > > 19:45:42.0 +1000 @@ -341,6 +341,7 @@ static int cryptd_thread(void > > *data) > > > > mutex_unlock(>mutex); > > > > + try_to_freeze(); > > schedule(); > > } while (!stop); > > I tried your patch, but when I apply it my kernel doesn't compile any more. I > get these warnings/errors: > > [...] > CC crypto/cryptd.o > crypto/cryptd.c: In function ‘cryptd_thread’: > crypto/cryptd.c:344: warning: implicit declaration of function ‘try_to_freeze’ > [...] > LD init/built-in.o > LD .tmp_vmlinux1 > crypto/built-in.o: In function `cryptd_thread': > cryptd.c:(.text+0xd7f5): undefined reference to `try_to_freeze' > make: *** [.tmp_vmlinux1] Error 1 Ah. You'll need to add #include near that start of crypto/cryptd.c. Sorry for forgetting that. Nigel signature.asc Description: This is a digitally signed message part
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: >> Is there anything I can do better to help myself figuring out this >> issue? As this is a modern laptop such things like a serial console are >> unavailable, but it would be nice to track things up over netconsole >> perhaps? >> >> I just need some bright and nice directions now ;) Hope someone finds >> this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) > > Can you boot with "hpet=disable" on the command line ? > Nope. It doesn't seem to have significant effect. Same time-bomb behavior: after an indeterminate period of uptime, the systems stops responding and cannot spawn new processes (current running ones still live on, strange). > If that does not help, please provide the output of /proc/timer_list. > This is with my latest iteration: http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 Normal boot on which it behaves as badly as reported: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 131736771907 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: , tick_sched_timer, S:01 # expires at 13173700 nsecs [in 228093 nsecs] #1: , it_real_fn, S:01 # expires at 131751277843 nsecs [in 14505936 nsecs] #2: , hrtimer_wakeup, S:01 # expires at 131802703679 nsecs [in 65931772 nsecs] #3: , hrtimer_wakeup, S:01 # expires at 131802705006 nsecs [in 65933099 nsecs] #4: , hrtimer_wakeup, S:01 # expires at 132412838830 nsecs [in 676066923 nsecs] #5: , it_real_fn, S:01 # expires at 137026607454 nsecs [in 5289835547 nsecs] #6: , hrtimer_wakeup, S:01 # expires at 141381493725 nsecs [in 9644721818 nsecs] #7: , hrtimer_wakeup, S:01 # expires at 170796028701 nsecs [in 39059256794 nsecs] .expires_next : 13173700 nsecs .hres_active: 1 .nr_events : 40634 .nohz_mode : 2 .idle_tick : 13172400 nsecs .tick_stopped : 0 .idle_jiffies : 4294799020 .idle_calls : 178848 .idle_sleeps: 133212 .idle_entrytime : 131736069830 nsecs .idle_sleeptime : 100895567465 nsecs .last_jiffies : 4294799033 .next_jiffies : 4294799039 .idle_expires : 13173600 nsecs jiffies: 4294799033 cpu: 1 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: , hrtimer_wakeup, S:01 # expires at 131737067173 nsecs [in 295266 nsecs] #1: , tick_sched_timer, S:01 # expires at 13173725 nsecs [in 478093 nsecs] #2: , hrtimer_wakeup, S:01 # expires at 139151071745 nsecs [in 7414299838 nsecs] #3: , hrtimer_wakeup, S:01 # expires at 139151133755 nsecs [in 7414361848 nsecs] #4: , hrtimer_wakeup, S:01 # expires at 139151154005 nsecs [in 7414382098 nsecs] .expires_next : 131737067173 nsecs .hres_active: 1 .nr_events : 31510 .nohz_mode : 2 .idle_tick : 13173425 nsecs .tick_stopped : 0 .idle_jiffies : 4294799030 .idle_calls : 151213 .idle_sleeps: 107018 .idle_entrytime : 131735193036 nsecs .idle_sleeptime : 108256832194 nsecs .last_jiffies : 4294799032 .next_jiffies : 4294799040 .idle_expires : 13174300 nsecs jiffies: 4294799033 Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 13173700 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: tick_handle_oneshot_broadcast tick_broadcast_mask: 0003 tick_broadcast_oneshot_mask: 0001 Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 1 next_event: 13173700 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 3 next_event: 131737067173 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt -- Alternate boot with hpet=disabled as suggested, but no better results: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0-hpet_disabled # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 269529706096 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180214106093436428 nsecs active
Re: [PATCH, RFT, v4] sata_mv: convert to new EH
On Sat, 2007-05-26 at 16:56 -0400, Jeff Garzik wrote: > Dave, any chance you could try 2.6.22-rc3 + my v4 patch, on a different > hard drive? Preferably a non-Maxtor, or at least not another Maxtor > 6L200S0. If that's a big deal, don't worry about it. I just want to > rule out buggy firmware and/or bad hard drive in your case. It is likely I can come up with at least one, and maybe two if I cannibalize my main machine... do you want results under all three kernels or just the v4 patch? 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: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Saturday 26 May 2007 22:33:13 Uwe Bugla wrote: > Am Samstag, 26. Mai 2007 21:57 schrieben Sie: > > Uwe Bugla wrote: > > > OK, applied this one against 2.6.22-rc3, assuming a typo error by you, > > > Andrew. > > > > > > Result is: No change: non functionable b44 device! > > > > Could you please send the following: > > > > 1. the output of lsmod from the non-functioning kernel > > Nonsense! > As I stated already, both modules (i. e. b44 and ssb) are loaded correctly. > So please read the thread before you post that, not vice versa! Ok, Uwe. Now I show you some real life examples how you and how someone who is polite answers to the same question: You: > Nonsense! > As I stated already, both modules (i. e. b44 and ssb) are loaded correctly. > So please read the thread before you post that, not vice versa! > They are already in the thread. So please leave me alone with those lazy > hints! Read bfore you post, not vice versa! Someone who is polite: > They are already in the thread. So you see the difference? And do you see why everybody in this thread is so pissed about you? -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RFT, v4] sata_mv: convert to new EH
dean gaudet wrote: On Fri, 25 May 2007, Jeff Garzik wrote: Already uncovered and fixed a few bugs in v3. Here's v4 of the sata_mv new-EH patch. you asked for test results with 2.6.21.3 ... that seems to boot fine, and i've tested reading from the disks only and it seems to be working fine. ditto for 2.6.22-rc3. but 2.6.22-rc3 + your v4 patch fails... i'll send you the serial console outputs offline. Well, I have the same hardware as dean, and do not see the BUG_ON/WARN_ON traces that he sees. These are the same two code locations that caused spewage before. This only difference I see is that he is testing with an NCQ-capable disk, and I am not -- which could be a very significant difference. Dave also appears to have an NCQ-capable disk. Dave's output (sent privately to me) was different -- errors and corruption -- rather than the BUG_ON/WARN_ON stuff both he and dean sent in March 2007, which is interesting. Dave, any chance you could try 2.6.22-rc3 + my v4 patch, on a different hard drive? Preferably a non-Maxtor, or at least not another Maxtor 6L200S0. If that's a big deal, don't worry about it. I just want to rule out buggy firmware and/or bad hard drive in your case. dean's output (backtraces matching March 2007 reports) was what I expected, and if I can reproduce that with an NCQ-capable disk locally, I should be able to fix it from there without trouble. Probably just some hardware bits accidentally kicking into NCQ mode, when they should not. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
udev regression? lsusb silent (no output) since 2.6.22-rc2 at least
Greg, Kay, kernel people,
Today I booted 2.6.22-rc2 on Ubunty Edgy Eft, and lsusb died on me:
[EMAIL PROTECTED]:~$ lsusb
[EMAIL PROTECTED]:~$ sudo lsusb
[EMAIL PROTECTED]:~$
This behaviour persists in rc4. This might be udev related. I'm running:
ii udev 093-0ubuntu18.0edgy2
USB does work fine.
Bit from strace:
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 4 entries */, 4096)= 112
close(3)= 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 4 entries */, 4096)= 112
getdents64(3, /* 0 entries */, 4096)= 0
close(3)= 0
(end of program)
[EMAIL PROTECTED]:~$ ls -l /dev/bus/usb -d
drwxr-xr-x 3 root root 80 2007-05-26 21:58 /dev/bus/usb
[EMAIL PROTECTED]:~$ ls -l /dev/bus/usb/
total 0
lrwxrwxrwx 1 root root 14 2007-05-26 21:58 devices -> .usbfs/devices
[EMAIL PROTECTED]:~$ ls -l /dev/bus/usb/devices
lrwxrwxrwx 1 root root 14 2007-05-26 21:58 /dev/bus/usb/devices ->
.usbfs/devices
[EMAIL PROTECTED]:~$ wc -l /dev/bus/usb/devices
95 /dev/bus/usb/devices
On another machine (debian etch), with an older kernel, where lsusb does
work:
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 4 entries */, 4096)= 96
close(3)= 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 4 entries */, 4096)= 96
getdents64(3, /* 0 entries */, 4096)= 0
close(3)= 0
open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 3 entries */, 4096)= 72
open("/dev/bus/usb/001/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/001/001", O_RDONLY) = 4
Any clues? Please let me know how I can help solve this problem!
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Extending boot protocol & bzImage for paravirt_ops
Rusty Russell wrote: >> >> + Bit 6 (write): KEEP_SEGMENTS >> +Protocol: 2.07+ >> +- if 0, reload the segment registers in the 32bit entry point. >> +- if 1, do not reload the segment registers in the 32bit entry point. >> +Assume that %cs %ds %ss %es are all set to flat segments with >> +a base of 0 (or the equivalent for their environment). > > You also want to skip the cli: perhaps a separate flag for this is > appropriate though. > Do we have *any* environment that enters the 32-bit code with interrupts enabled? I would think that is unsafe no matter how you do it. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm2: HDAPS? BUG: at kernel/mutex.c:311
2007/5/14, Satyam Sharma <[EMAIL PROTECTED]>: On 5/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > Hi Satyam, > > On Saturday 12 May 2007 01:45, Satyam Sharma wrote: > > Seems to be good-looking code! > > Thanks. Do you have the hardware? Were you able to test the patch? Oh, sorry, no. I was actually referring to the input-polldev code. Let's hope Matt can test and ack this. Thanks, Satyam - Hi all, Since i still had that BUG on my T43 running a 2.6.22-rc2-mm1 kernel, I tried that patch. It sounds like this has solved the bug since I can't find any trace of that issue anymore once the patch is applied. Thanks for the patch, Regards, Cédric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:57 schrieben Sie: > Uwe Bugla wrote: > > OK, applied this one against 2.6.22-rc3, assuming a typo error by you, > > Andrew. > > > > Result is: No change: non functionable b44 device! > > Could you please send the following: > > 1. the output of lsmod from the non-functioning kernel Nonsense! As I stated already, both modules (i. e. b44 and ssb) are loaded correctly. So please read the thread before you post that, not vice versa! > > 2. the output of dmesg from the non-functioning kernel > > 3. your .config used to create your non-functioning kernel. > They are already in the thread. So please leave me alone with those lazy hints! Read bfore you post, not vice versa! > Thanks, > > Larry Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)
On Saturday, 26 May 2007 19:37, Martin Steigerwald wrote: > Am Mittwoch 25 April 2007 schrieb Pavel Machek: > > Hi! > > > > > This is why there's a lot to be said for > > > > > > echo mem > /sys/power/state > > > > > > and being able to follow the path through _one_ object (the kernel) > > > over trying to figure out the interaction between many different > > > parts with different versions. > > > > The 'promise' is 'if you can get echo disk > /sys/power/state working, > > uswsusp will work. too'. IOW it should be ok to debug the in-kernel > > parts, only. > > Hello Nigel, Pavel, Rafael and everyone else who is involved, > > I would like to ask what come out of the suspend2 merge discussion. Nigel > just told that suspend2 likely won't be merged anytime soon and thats its > business as usual: > > - > It's pretty much business as usual. Linus doesn't want another > implementation merged, and he wants the three of us (Pavel, Rafael and > myself) to agree on a way forward. He also believes that we're > approaching things from the wrong direction at the moment. Funnily > enough, this is the one area on which we do all agree. > - > http://lists.suspend2.net/lurker/message/20070510.021641.fe306add.en.html > > > Has there been any further discussion and preferably agreement on the way > to go forward? The outcome was, more-or-less, that we'll work on merging suspend2 or at least some parts of it. However, in the meantime there have been some discussions implying that we have some important problems with suspend/hibernation that suspend2 doesn't solve and that IMHO are more urgent than the merging of suspend2 right not. So, as far as I'm concerned, the plan is to fix the more urgent problems first and to work on merging suspend2 as far as there's time to do this. The problem is there are only a few people working on it and there's a lot to do, so I can only ask you to be patient. ;-) Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Larry Finger <[EMAIL PROTECTED]> : [...] > 2. the output of dmesg from the non-functioning kernel > > 3. your .config used to create your non-functioning kernel. They are already in the thread. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: software suspend doesn't work with 2.6.22-rc3
On Saturday, 26 May 2007 13:55, Herbert Xu wrote: > On Sat, May 26, 2007 at 09:14:00PM +1000, Nigel Cunningham wrote: > > > > You have the cryptd Kconfig option in (at least in rc3) - presumably > > Maximillian has been too keen and turned it on before you were ready :) > > It does make sense for it to be the problem. Without PF_NOFREEZE set, > > the refrigerator code will try to get it to enter the freezer, and > > without the try_to_freeze(), it will just loop and freezing will fail. > > OK that makes sense. I'll apply your patch. Please add '#include ' to crypto/cryptd.c for the patch to compile. FYI, I'm going to post a patch that will make this try_to_freeze() unnecessary, but I don't think it'll make it into 2.6.22. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: software suspend doesn't work with 2.6.22-rc3
On Saturday, 26 May 2007 14:49, Maximilian Engelhardt wrote: > On Saturday 26 May 2007, Nigel Cunningham wrote: > > Hi. > > > > On Sat, 2007-05-26 at 11:28 +0200, Maximilian Engelhardt wrote: > > > Hello, > > > > > > When I try software suspend on my laptop it always returns to my running > > > system after some time. > > > This is what's logged by the kernel: > > > > > > swsusp: Basic memory bitmaps created > > > Stopping tasks ... > > > Stopping kernel threads timed out after 20 seconds (1 tasks refusing to > > > freeze): > > > cryptd > > > Restarting tasks ... done. > > > swsusp: Basic memory bitmaps freed > > > > > > I have no idea what's the problem, but if you tell me what I should do I > > > can create debugging information and/or test patches. > > > > Could you try this patch, please? It should help. > > > > Herbert, is this right? If cryptd is going to be used for block devs, > > the task should probably be PF_NOFREEZE (or whatever it is today) > > instead. > > > > Regards, > > > > Nigel > > > > crypto/cryptd.c |1 + > > include/linux/freezer.h |3 +++ > > kernel/power/process.c |2 +- > > 3 files changed, 5 insertions(+), 1 deletion(-) > > diff -ruNp 991-fix-cryptd.patch-old/crypto/cryptd.c > > 991-fix-cryptd.patch-new/crypto/cryptd.c --- > > 991-fix-cryptd.patch-old/crypto/cryptd.c2007-05-19 18:16:47.0 > > +1000 +++ 991-fix-cryptd.patch-new/crypto/cryptd.c 2007-05-26 > > 19:45:42.0 +1000 @@ -341,6 +341,7 @@ static int cryptd_thread(void > > *data) > > > > mutex_unlock(>mutex); > > > > + try_to_freeze(); > > schedule(); > > } while (!stop); > > I tried your patch, but when I apply it my kernel doesn't compile any more. I > get these warnings/errors: You need to add '#include ' to crypto/cryptd.c . Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [condingstyle] Add chapter on tests
Based in part on Auke's patch.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
Documentation/CodingStyle | 74 +++---
1 file changed, 64 insertions(+), 10 deletions(-)
Index: linux-2.6.22-rc3/Documentation/CodingStyle
===
--- linux-2.6.22-rc3.orig/Documentation/CodingStyle
+++ linux-2.6.22-rc3/Documentation/CodingStyle
@@ -407,7 +407,61 @@ out:
return result;
}
- Chapter 8: Commenting
+ Chapyer 8: Tests
+
+Testing return values from function calls can get complex when you need
+to re-use the value later on. You should store the value before doing
+any tests on it. Do not assign values inside a condition to another
+variable.
+
+ err = test_something();
+ if (err) {
+ printk(KERN_ERR "Error: test_something() failed\n");
+ return err;
+ }
+
+Testing for a flag, as done in the following example, is redundant and
+can be shortened.
+
+ if ((v & GFP_KERNEL) == GFP_KERNEL)
+ return;
+
+should become
+
+ if (v & GFP_KERNEL)
+ return;
+
+The same goes for functions that return a bool:
+
+ if (is_prime(number) == true)
+ return 0;
+ if (is_prime(number) == false)
+ return 1;
+
+should be:
+
+ if (is_prime(number))
+ return 0;
+ if (!is_prime(number))
+ return 1;
+
+As far as pointers or functions returning an integer are concerned,
+using long form tests helps to distinguish between pointers and bools
+or functions returning boolean or integer, respectively.
+Examples are:
+
+ if (p == NULL)
+ return 1;
+ if (!p)
+ return 0;
+
+ if (strcmp(haystack, needle) == 0)
+ return 1;
+ if (!strcmp(haystack, needle))
+ return 0;
+
+
+ Chapter 9: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
try to explain HOW your code works in a comment: it's much better to
@@ -447,7 +501,7 @@ multiple data declarations). This leave
item, explaining its use.
- Chapter 9: You've made a mess of it
+ Chapter 10: You've made a mess of it
That's OK, we all do. You've probably been told by your long-time Unix
user helper that "GNU emacs" automatically formats the C sources for
@@ -495,7 +549,7 @@ re-formatting you may want to take a loo
remember: "indent" is not a fix for bad programming.
- Chapter 10: Kconfig configuration files
+ Chapter 11: Kconfig configuration files
For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different. Lines under a "config" definition
@@ -531,7 +585,7 @@ For full documentation on the configurat
Documentation/kbuild/kconfig-language.txt.
- Chapter 11: Data structures
+ Chapter 12: Data structures
Data structures that have visibility outside the single-threaded
environment they are created and destroyed in should always have
@@ -562,7 +616,7 @@ Remember: if another thread can find you
have a reference count on it, you almost certainly have a bug.
- Chapter 12: Macros, Enums and RTL
+ Chapter 13: Macros, Enums and RTL
Names of macros defining constants and labels in enums are capitalized.
@@ -617,7 +671,7 @@ The cpp manual deals with macros exhaust
covers RTL which is used frequently with assembly language in the kernel.
- Chapter 13: Printing kernel messages
+ Chapter 14: Printing kernel messages
Kernel developers like to be seen as literate. Do mind the spelling
of kernel messages to make a good impression. Do not use crippled
@@ -628,7 +682,7 @@ Kernel messages do not have to be termin
Printing numbers in parentheses (%d) adds no value and should be avoided.
- Chapter 14: Allocating memory
+ Chapter 15: Allocating memory
The kernel provides the following general purpose memory allocators:
kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API
@@ -647,7 +701,7 @@ from void pointer to any other pointer t
language.
- Chapter 15: The inline disease
+ Chapter 16: The inline disease
There appears to be a common misperception that gcc has a magic "make me
faster" speedup option called "inline". While the use of inlines can be
@@ -674,7 +728,7 @@ appears outweighs the potential value of
something it would have done anyway.
- Chapter 16: Function return values and names
+ Chapter 17: Function return values and names
Functions can return values of many different kinds, and one of the
most common is a value indicating whether the function succeeded or
@@ -708,7 +762,7 @@ result. Typical examples would be funct
NULL
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Uwe Bugla wrote: OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew. Result is: No change: non functionable b44 device! Could you please send the following: 1. the output of lsmod from the non-functioning kernel 2. the output of dmesg from the non-functioning kernel 3. your .config used to create your non-functioning kernel. Thanks, Larry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > Uwe, please try the following patch:
> >
> > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > ===
> > --- bu3sch-wireless-dev.orig/drivers/net/b44.c 2007-05-18
> > 18:09:50.0 +0200 +++
> > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > +0200
> > @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> > printk("%2.2x%c", dev->dev_addr[i],
> >i == 5 ? '\n' : ':');
> >
> > +#if 0
> > /* Initialize phy */
> > spin_lock_irq(>lock);
> > b44_chip_reset(bp);
> > spin_unlock_irq(>lock);
> > +#endif
> >
> > return 0;
>
> Against what kernel please?
> Just try to be a bit more eloquent, man!
Against a kernel which does not work for you, of course.
Sometimes I wonder... (no better not say that).
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> Uwe, please try the following patch:
>
> Index: bu3sch-wireless-dev/drivers/net/b44.c
> ===
> --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> 18:09:50.0 +0200 +++
> bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0 +0200
> @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> printk("%2.2x%c", dev->dev_addr[i],
> i == 5 ? '\n' : ':');
>
> +#if 0
> /* Initialize phy */
> spin_lock_irq(>lock);
> b44_chip_reset(bp);
> spin_unlock_irq(>lock);
> +#endif
>
> return 0;
Against what kernel please?
Just try to be a bit more eloquent, man!
Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 20:19 schrieben Sie: > On Sat, 26 May 2007 20:03:17 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > Ok, please take git and get my development tree and try with that: > > > > git clone http://bu3sch.de/git/wireless-dev.git > > > > It's based on 2.6.22-rc1 and it works fine for me. > > Uwe has a slow connection, and getting the whole git thing > set up would be quite a lump of effort. > > I prepared a diff of the above tree against 2.6.21-rc3. It is at > http://userweb.kernel.org/~akpm/git-mb.patch.gz OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew. Result is: No change: non functionable b44 device! Thank you for your help! Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCIE
Grant Grundler wrote: > On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote: >> Roland Dreier wrote: >>> > I am now wondering whether the usage of MSI would help in this case and >>> > that i should be using enable_msi before request_irq ? >>> >>> MSI interrupts are never shared. So if pci_enable_msi() succeeds, you >>> can be sure that the interrupts you get with that IRQ number are >>> coming from your device. >>> >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > I'm not sure...but my guess is not. Who ever "just knows", could you > please submit a patch to Documentation/MSI-HOWTO.txt ? did a bit of search in the sources, e1000 does avoid using IRQF_SHARED. tg3 uses IRQF_SAMPLE_RANDOM, don't understand why SAMPLE_RANDOM though. >> Another question would be if the device supports multiple messages, MSIX >> should be used ? > > Yes. Assuming the device supports multiple MSI-X messages. > What i read from the specs: 6.2 Message Signals Interrupts The MSI logic is responsible for generating the MSI messages.MSI is an optional feature in PCI Express that enables a device to request a service by writing a system-specified message to a system-specified address (PCI Express DWORD memory write transaction). The write transaction address specifies the MSI message destination and the write transaction data specifies the message including a message “ID”. During device configuration, system software reads the capability list of the logic core to find out whether it supports MSI, and if yes how many different MSI messages it is requesting. Using the multiple message feature allows an PCI Express device to give different MSI messages a unique message ID (e.g. an MSI message initiated by interrupt source #1 gets a different message ID than an MSI message initiated by interrupt source#2). The max. number of requested MSI messages is 32 and must be aligned to a power of two (1,2,4,8,16, or 32). The core will be configured for 32 requested messages, but optionally the default setting of 32 requested messages can be modified by the BOOT logic immediately after power-on-reset (i.e. before device configuration). After reading the capability list, system software initializes the following parameters: - Multiple Message Enable field Defines the number of allowed messages, which is either all or a subsetof the number of requested messages. For example, a PCI Express device can request 4messages and be allocated either four, two, or one message. The number of messages requested and allocated are aligned to a power of two (a PCI Express device that requires three messages must request four) - MSI message destination address Defines the (physical) message destination address of MSI messages. - MSI message data Defines the message data of MSI messages. The main features of the MSI logic are: • MSI capability - 32 different messages - programmable ID in MSI message data field - programmable TC in MSI message address field • Support for MSI delay timer • Support for the following interrupt sources: - DMA channel tag_ack (“buffer_done”) interrupts (12x) - DMA channel overflow interrupts (12x) - A/V interrupts (8x) - I2C interrupts (2x) - unmapped_tc interrupt (1x) - external interrupts from GPIO (16x) - all interrupts edge sensitive with programmable edge polarity - round-robin arbitration between multiple, simultaneous interrupt requests • Support for interrupt masking (i.e. enable/disable) • Support for INT-A emulation • DTL-MMIO target interface for SW access - 4Kbyte address aperture (12bit address / 32bit aligned) - 32bit read and write data >> In such a context, if i request for say more than the messages that i >> need, say i request 16 messages, but use only 1 or 2, that does bear any >> consequences ? > > Yes. One is allocating IRQ vectors from a finite number of vectors. > But this normally isn't a problem until one gets to larger machines that > have more than 4-8 PCI-e or PCI-X slots. Ok. Alongwith this, i am a bit confused with the mailbox approach of sending messages, every register type has it's own set of interrupt registers (for example I2C, say I2C has it's own set of 32 STATUS bitfields for it's interrupt, the same goes for the others) Another aspect is the DTL-MMIO interface, which isn't defined any place. Using the base addresses as an offset to the normal MMIO obtained using pci_resource_*/ioremap() doesn't seem to work at all. Seems like it needs some kind of a translation (guessing here, still no clue yet) The device supports 50 MSI interrupt sources Somewhere else it mentions thus: 6.4Global Register (GREG) The logic provides a set of global registers there are accessible via a device transaction level protocol memory mapped input output interface. Primarily, the global registers are used to control and/or observe logic inside the SAA7160 that is not directly accessible via the device status network. The main features of the GREG logic are: • 16 general
Re: [PATCH 2/2] [condingstyle] Add chapter on tests
On May 25 2007 10:25, Auke Kok wrote:
>diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
>index f518395..3635b38 100644
>--- a/Documentation/CodingStyle
>+++ b/Documentation/CodingStyle
>@@ -393,7 +393,7 @@ int fun(int a)
> int result = 0;
> char *buffer = kmalloc(SIZE);
>
>- if (buffer == NULL)
>+ if (!buffer)
> return -ENOMEM;
Please don't do this. With ==NULL/!=NULL, it is clear what
could be (integer or pointer) without needing
to look it up. It also reads quite strange: "if not buffer".
For bools ('adjectives' / 'is a'), it works, not so much for ptrs.
Hence:
>+If you give your variables and pointers good names, there is never a need
>+to compare the value stored in that variable to NULL or true/false, so
>+omit all that and keep it short.
>+ ptr = s->next;
>+ if (!ptr)
>+ return;
Not agreed.
>+
>+ v = (read_byte(register));
>+ if (v & mask)
>+ return;
well, yes.
>+ if (is_prime(number))
Yes.
And I'd also like to mention one rather special case where I'd rather
like to see ==0 than ! for clarity (!strcmp looks like !streq, so
one needs to look twice to get it):
if (!strcmp(hay, needle))
At least don't force the '!' doctrine.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Uwe, please try the following patch:
Index: bu3sch-wireless-dev/drivers/net/b44.c
===
--- bu3sch-wireless-dev.orig/drivers/net/b44.c 2007-05-18 18:09:50.0
+0200
+++ bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
+0200
@@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
printk("%2.2x%c", dev->dev_addr[i],
i == 5 ? '\n' : ':');
+#if 0
/* Initialize phy */
spin_lock_irq(>lock);
b44_chip_reset(bp);
spin_unlock_irq(>lock);
+#endif
return 0;
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Saturday 26 May 2007 20:58:37 Uwe Bugla wrote: > Am Samstag, 26. Mai 2007 20:41 schrieben Sie: > > On 5/26/07, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > > > > Yes, sure! But the help text is very unlucky and humble, and it is not > > > > clear enough in the sense of being distinctive enough, just clear and > > > > comprehensive. > > > > > > Why don't you simply submit a patch to change the helptext then? > > > > Is that ok ? > > > > Discourage people from deselecting B44_PCI > > > > Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> > > > > --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 > > +++ kernel/drivers/net/Kconfig 2007-05-26 20:38:15.0 +0200 > > @@ -1449,7 +1449,7 @@ > > help > > Support for b44 PCI devices. > > > > - Say Y > > + Unless you know what you are doing, say Y here. > > > > config FORCEDETH > > tristate "nForce Ethernet support" > > No, That is NOT OK! That's nothing but a joke, and if it is a joke : ) > it hits well in Mister Buesches direction. In so far it's > well-done : ) : ) : ) See what I meant, Benoit? > To be honest: > > I expect at least TWO explained cases: > > A. The case in which the b44 module is a PCI module (onboard, additional PCI > card etc.). > > B. At least one well described case in which the b44 module is a bus > independent one. You still didn't get it, right? b44-ssb is a SSB device driver. No PCI, nothing. To get this working on PCI you need to enable the PCI glue. Which is enabled by default. It even includes the comment "Say Y". If you say N nevertheless it's your fault. What's so hard to understand about this? We have LOTS of drivers in the kernel that work _exactly_ the same way. There is a base module to drive the hardware and several glue drivers. If you de-select the glue driver it doesn't work. If you use your old config and do not DISABLE some option you will not experience a regression (at least regarding to the kconfig stuff. There's still your transmission bug left). > Apart from that, it is Michael's task to explain the what and why, not mine > and not yours! It is him that wants his stuff being pulled into mainline, and My task is _nothing_. This is opensource. If you don't like something about it, go and fix it. But don't say it's the _task_ of others to fix things you don't like. I am not payed to do this for you. Though, I'd like to resolve it. > in so far he very well can do the "dirty work" of documentation, explanation. I explained it several times now. I'm not sure what else I should say about it. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 4
btw - does in-kernel lzo scale on SMP systems ? is it a matter of lzo builtin compression or a matter of the component using in-kernel lzo compression ? if i write/read data on reiser4 filesystem with lzo compression on - will all CPUs being used ? just curious here, because i remember reading about a scale problem with zfs filesystem and gzip compression on solaris, so i'm just curious what to expect on linux. regards roland ps: btw - there is a smp aware lzop utility at lemley.net/lzop_patches/lzop.html Hi, This is kernel port of LZO1X compressor and LZO1X decompressor (safe version only). * Changes since 'take 3' (Full Changelog after this): 1) Removed 'unsafe' decompressor - hence also do away with symlinks in Makefiles. 2) Rolled back changes where I replaced COPY4 with memcpy() calls. This seemed to be causing too much perf. loss as shown by Richard's tests. Need perf. testing again to confirm that this patch has perf. comparable to original LZO code/Richard's patch. 3) Some functions were inlined (DX2, DX3 etc.) - this also seemed to be one of factors for perf. loss. Changed them back Macros. 4) Added back the 'register' keyword - again seemed to me one of factors for perf. loss. Once I pinpoint exact reason for bad perf., I will do above cleanups again. But this should not be reason for non-inclusion in mainline. These are only minor cleanups. Richard, can you please provide perf. results for this patch also? Also, can you please mail back latest version of your LZO patch? In meantime, I will try to include benchmarking support to the 'compress-test' module. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 8473] New: Oops: 0010 [1] SMP
Le jeudi 17 mai 2007 à 18:59 +0200, Nicolas Mailhot a écrit : > Le jeudi 17 mai 2007 à 09:45 -0700, Randy Dunlap a écrit : > > > Can you boot with "kstack=32" so that we can see more of the stack? > > I can try. It's not triggering quickly though Seems I was completely wrong about the trigger, but anyway it happened again, this time on 2.6.22-rc2.mm1.cfs14 (and I had kept kstack=32) BUG: using smp_processor_id() in preemptible [0001] code: bash/3857 caller is oops_begin+0xb/0x6f Call Trace: [] show_trace+0x34/0x4f [] dump_stack+0x12/0x17 [] debug_smp_processor_id+0xad/0xbc [] oops_begin+0xb/0x6f [] do_page_fault+0x66a/0x7c0 [] error_exit+0x0/0x84 Unable to handle kernel NULL pointer dereference at RIP: [<>] PGD bdd2067 PUD c133067 PMD 0 Oops: 0010 [1] PREEMPT SMP CPU 1 Pid: 3857, comm: bash Not tainted 2.6.22-0.8.rc2.mm1.cfs14.fc8.nim #1 RIP: 0010:[<>] [<>] RSP: 0018:81000cb03ee0 EFLAGS: 00010296 RAX: 8044dbc0 RBX: 81000c3aa8c0 RCX: 7fff549dcae4 RDX: 5410 RSI: 81000c3aa8c0 RDI: 81000ba913d8 RBP: 7fff549dcae4 R08: R09: R10: 0008 R11: 0246 R12: 5410 R13: 00ff R14: 00ff R15: FS: 2b06560d8f40() GS:810004017180() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: CR3: 0bc55000 CR4: 06e0 Process bash (pid: 3857, threadinfo 81000cb02000, task 81000adc59a0) Stack: 8028ada9 81000c3aa8c0 7fff549dcae4 7fff549dcae4 8028b016 5410 00ff 81000c3aa8c0 7fff549dcae4 5410 00ff 8028b088 80209571 7fff549dce87 0f11 7fff549dcfb8 7fff549dddb0 802095dc 0246 0008 ffda 7fff549dcae4 5410 00ff 0010 003d340c9117 Call Trace: Inexact backtrace: [] do_ioctl+0x55/0x6b [] vfs_ioctl+0x257/0x270 [] sys_ioctl+0x59/0x79 [] tracesys+0xdc/0xe1 INFO: lockdep is turned off. Code: Bad RIP value. RIP [<>] RSP CR2: -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Saturday 26 May 2007 18:13:09 Andrew Morton wrote: > > I ask to try wireless-dev, as the driver works perfectly fine > > for me there, but he refuses to try it, too. So I'm stuck. > > I don't think he knows how to obtain it. > > Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current > wireless tree. That's a patch against 2.6.22-rc3. Could you please test > that? If that works then we know that the bug probably lies outside the > b44 driver (or it was subsequently fixed). I just tried this patch on my BCM4401-B0 and it works there, too. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 20:41 schrieben Sie: > On 5/26/07, Michael Buesch <[EMAIL PROTECTED]> wrote: > > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > > > Yes, sure! But the help text is very unlucky and humble, and it is not > > > clear enough in the sense of being distinctive enough, just clear and > > > comprehensive. > > > > Why don't you simply submit a patch to change the helptext then? > > Is that ok ? > > Discourage people from deselecting B44_PCI > > Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> > > --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 > +++ kernel/drivers/net/Kconfig2007-05-26 20:38:15.0 +0200 > @@ -1449,7 +1449,7 @@ > help > Support for b44 PCI devices. > > - Say Y > + Unless you know what you are doing, say Y here. > > config FORCEDETH > tristate "nForce Ethernet support" No, That is NOT OK! That's nothing but a joke, and if it is a joke : ) it hits well in Mister Buesches direction. In so far it's well-done : ) : ) : ) To be honest: I expect at least TWO explained cases: A. The case in which the b44 module is a PCI module (onboard, additional PCI card etc.). B. At least one well described case in which the b44 module is a bus independent one. Apart from that, it is Michael's task to explain the what and why, not mine and not yours! It is him that wants his stuff being pulled into mainline, and in so far he very well can do the "dirty work" of documentation, explanation. But the issue is: He is not ready to DO that! Only if it fires back! Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On Saturday 26 May 2007 20:41:09 Benoit Boissinot wrote: > On 5/26/07, Michael Buesch <[EMAIL PROTECTED]> wrote: > > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > > > Yes, sure! But the help text is very unlucky and humble, and it is not > > > clear > > > enough in the sense of being distinctive enough, just clear and > > > comprehensive. > > > > Why don't you simply submit a patch to change the helptext then? > > Is that ok ? > > Discourage people from deselecting B44_PCI To me this is ok. But I think I have no voting right here. Uwe has to decide which helptext he would understand. ;) > Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> > > --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 > +++ kernel/drivers/net/Kconfig2007-05-26 20:38:15.0 +0200 > @@ -1449,7 +1449,7 @@ > help > Support for b44 PCI devices. > > - Say Y > + Unless you know what you are doing, say Y here. > > config FORCEDETH > tristate "nForce Ethernet support" > > -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Sat, 26 May 2007, Kyle Moffett wrote: > AppArmor). On the other hand, if you actually want to protect the _data_, > then tagging the _name_ is flawed; tag the *DATA* instead. Bingo. (This is how traditional Unix DAC has always functioned, and is what SELinux does: object labeling). - James -- James Morris <[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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Fri, 25 May 2007, Crispin Cowan wrote: > Finally, AA doesn't care what the contents of the executable are. We > assume that it is a copy of metasploit or something, and confine it to > access only the resources that the policy says. As long as these resources are only files. There is no confinement beyond that. - James -- James Morris <[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: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
On 5/26/07, Michael Buesch <[EMAIL PROTECTED]> wrote: On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > Yes, sure! But the help text is very unlucky and humble, and it is not clear > enough in the sense of being distinctive enough, just clear and > comprehensive. Why don't you simply submit a patch to change the helptext then? Is that ok ? Discourage people from deselecting B44_PCI Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 +++ kernel/drivers/net/Kconfig 2007-05-26 20:38:15.0 +0200 @@ -1449,7 +1449,7 @@ help Support for b44 PCI devices. - Say Y + Unless you know what you are doing, say Y here. config FORCEDETH tristate "nForce Ethernet support" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCIE
On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote: > Roland Dreier wrote: > > > I am now wondering whether the usage of MSI would help in this case and > > > that i should be using enable_msi before request_irq ? > > > > MSI interrupts are never shared. So if pci_enable_msi() succeeds, you > > can be sure that the interrupts you get with that IRQ number are > > coming from your device. > > > > i presume then i shouldn't be using IRQF_SHARED, if using MSI. I'm not sure...but my guess is not. Who ever "just knows", could you please submit a patch to Documentation/MSI-HOWTO.txt ? > Another question would be if the device supports multiple messages, MSIX > should be used ? Yes. Assuming the device supports multiple MSI-X messages. > In such a context, if i request for say more than the messages that i > need, say i request 16 messages, but use only 1 or 2, that does bear any > consequences ? Yes. One is allocating IRQ vectors from a finite number of vectors. But this normally isn't a problem until one gets to larger machines that have more than 4-8 PCI-e or PCI-X slots. Typically, one will limit the number of vectors to the number of CPUs in the system or to how many different events the device can signal. > > But using MSI does not work on all systems, so your driver needs to > > work with standard (possibly shared) INTx interrupts too. And you > > should probably provide at least a module flag to disable the use of > > MSI, to avoid problems on buggy systems. > > I should probably look for CONFIG_PCI_MSI and check whether the system > supports MSI pci_enable_msi() ? pci_enable_msi() will fail if the system doesn't support MSI or something else goes wrong with the call (e.g. already setup). hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
