Re: 2.6.24-rc2 breaks nVidia MCP51 High Definition Audio
On Thu, 8 Nov 2007, Takashi Iwai wrote: > At Thu, 8 Nov 2007 08:38:18 -0500 (EST), > Gerhard Mack wrote: > > > > On Thu, 8 Nov 2007, Takashi Iwai wrote: > > > > > At Wed, 7 Nov 2007 19:07:07 -0500 (EST), > > > Gerhard Mack wrote: > > > > > > > > On Wed, 7 Nov 2007, Andrew Morton wrote: > > > > > > > > > Date: Wed, 7 Nov 2007 15:21:27 -0800 > > > > > From: Andrew Morton <[EMAIL PROTECTED]> > > > > > To: Gerhard Mack <[EMAIL PROTECTED]> > > > > > Cc: linux-kernel@vger.kernel.org, Jaroslav Kysela <[EMAIL PROTECTED]>, > > > > > Takashi Iwai <[EMAIL PROTECTED]>, Rafael J. Wysocki <[EMAIL > > > > > PROTECTED]> > > > > > Subject: Re: 2.6.24-rc2 breaks nVidia MCP51 High Definition Audio > > > > > > > > > > > On Wed, 7 Nov 2007 17:39:41 -0500 (EST) Gerhard Mack <[EMAIL > > > > > > PROTECTED]> wrote: > > > > > > hello, > > > > > > > > > > > > This worked fine in 2.6.23 but now the kernel no longer sees my > > > > > > audio > > > > > > controller. > > > > > > > > > > > > 00:10.1 Audio device: nVidia Corporation MCP51 High Definition > > > > > > Audio (rev > > > > > > a2) > > > > > > 00:10.1 0403: 10de:026c (rev a2) > > > > > > > > > > > > Let me know if I can provide more info or test patches. > > > > > > > > > > > > > > > > Please provide the output of `dmesg -s 100' for both 2.6.23 > > > > > and 2.6.24-rc3, thanks. > > > > > > > > > > Are you sure that the driver is suitably configured? Sometimes > > > > > we like to fiddle config options so that a `make oldconfig' will go > > > > > and > > > > > unconfigure drivers which you need. > > > > > > > > Found an option for generic HD audio and enabled that with only > > > > marginally > > > > better results. Now instead of not detecting my card it's showing a > > > > single volume control in the mixer and not providing any sound at all. > > > > > > > > 2.6.23: > > > > Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 > > > > 09:12:58 2007 UTC). > > > > ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 > > > > ACPI: PCI Interrupt :00:10.1[B] -> Link [AAZA] -> GSI 22 (level, > > > > low) > > > > -> IRQ 22 > > > > PCI: Setting latency timer of device :00:10.1 to 64 > > > > ALSA device list: > > > > #0: HDA NVidia at 0xfe024000 irq 22 > > > > GACT probability on > > > > > > > > 2.6.24-rc2: > > > > Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Oct 23 > > > > 06:09:18 2007 UTC). > > > > ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 > > > > ACPI: PCI Interrupt :00:10.1[B] -> Link [AAZA] -> GSI 22 (level, > > > > low) > > > > -> IRQ 22 > > > > PCI: Setting latency timer of device :00:10.1 to 64 > > > > ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011d8000101f761] > > > > ALSA device list: > > > > #0: HDA NVidia at 0xfe024000 irq 22 > > > > GACT probability on > > > > > > Both look OK. > > > > > > Please show your kernel config and /proc/asound/card0/codec#* > > > contents. Did you choose CONFIG_SND_HDA_CODEC_* properly? > > > > > > Also, please be more specific about your hardware. The implementation > > > of HD-audio stuff is deifferent greatly among products. It's very > > > important to know what kind of machine (h/w vendor, product name, > > > model, etc) to identify whether the configuration is known or not > > > (i.e. it was really supported or it worked just casually). > > > > The machine is an Asus M2NPV-VM motherboard with an Nforce MCP51 chpset. > > and there is not an CONFIG_SND_HDA_CODEC_ option for NVIDIA so I selected > > generic instead. > > That's the problem. MCP51 is the controller chip, not a codec chip. > It's always supported by snd-hda-intel driver. CONFIG_SND_HDA_CODEC_* > are configs to choose codec chips. > > Simply select all CONFIG_SND_HDA_CODEC_*=y if you are not sure (as > they are default=y). I guess CONFIG_SND_HDA_CODEC_ANALOG=y should > suffice but selecting others won't hurt except for a small memory > footprint. > Codec: Analog Devices AD1986A Address: 0 Vendor Id: 0x11d41986 Subsystem Id: 0x104381b3 Revision Id: 0x100500 Works like a charm now, thanks. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.24-rc2 breaks nVidia MCP51 High Definition Audio
On Thu, 8 Nov 2007, Takashi Iwai wrote: At Thu, 8 Nov 2007 08:38:18 -0500 (EST), Gerhard Mack wrote: On Thu, 8 Nov 2007, Takashi Iwai wrote: At Wed, 7 Nov 2007 19:07:07 -0500 (EST), Gerhard Mack wrote: On Wed, 7 Nov 2007, Andrew Morton wrote: Date: Wed, 7 Nov 2007 15:21:27 -0800 From: Andrew Morton [EMAIL PROTECTED] To: Gerhard Mack [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org, Jaroslav Kysela [EMAIL PROTECTED], Takashi Iwai [EMAIL PROTECTED], Rafael J. Wysocki [EMAIL PROTECTED] Subject: Re: 2.6.24-rc2 breaks nVidia MCP51 High Definition Audio On Wed, 7 Nov 2007 17:39:41 -0500 (EST) Gerhard Mack [EMAIL PROTECTED] wrote: hello, This worked fine in 2.6.23 but now the kernel no longer sees my audio controller. 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:10.1 0403: 10de:026c (rev a2) Let me know if I can provide more info or test patches. Please provide the output of `dmesg -s 100' for both 2.6.23 and 2.6.24-rc3, thanks. Are you sure that the driver is suitably configured? Sometimes we like to fiddle config options so that a `make oldconfig' will go and unconfigure drivers which you need. Found an option for generic HD audio and enabled that with only marginally better results. Now instead of not detecting my card it's showing a single volume control in the mixer and not providing any sound at all. 2.6.23: Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 ACPI: PCI Interrupt :00:10.1[B] - Link [AAZA] - GSI 22 (level, low) - IRQ 22 PCI: Setting latency timer of device :00:10.1 to 64 ALSA device list: #0: HDA NVidia at 0xfe024000 irq 22 GACT probability on 2.6.24-rc2: Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Oct 23 06:09:18 2007 UTC). ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 ACPI: PCI Interrupt :00:10.1[B] - Link [AAZA] - GSI 22 (level, low) - IRQ 22 PCI: Setting latency timer of device :00:10.1 to 64 ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011d8000101f761] ALSA device list: #0: HDA NVidia at 0xfe024000 irq 22 GACT probability on Both look OK. Please show your kernel config and /proc/asound/card0/codec#* contents. Did you choose CONFIG_SND_HDA_CODEC_* properly? Also, please be more specific about your hardware. The implementation of HD-audio stuff is deifferent greatly among products. It's very important to know what kind of machine (h/w vendor, product name, model, etc) to identify whether the configuration is known or not (i.e. it was really supported or it worked just casually). The machine is an Asus M2NPV-VM motherboard with an Nforce MCP51 chpset. and there is not an CONFIG_SND_HDA_CODEC_ option for NVIDIA so I selected generic instead. That's the problem. MCP51 is the controller chip, not a codec chip. It's always supported by snd-hda-intel driver. CONFIG_SND_HDA_CODEC_* are configs to choose codec chips. Simply select all CONFIG_SND_HDA_CODEC_*=y if you are not sure (as they are default=y). I guess CONFIG_SND_HDA_CODEC_ANALOG=y should suffice but selecting others won't hurt except for a small memory footprint. Codec: Analog Devices AD1986A Address: 0 Vendor Id: 0x11d41986 Subsystem Id: 0x104381b3 Revision Id: 0x100500 Works like a charm now, thanks. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.24-rc2 breaks nVidia MCP51 High Definition Audio
hello, This worked fine in 2.6.23 but now the kernel no longer sees my audio controller. 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:10.1 0403: 10de:026c (rev a2) Let me know if I can provide more info or test patches. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc2 breaks nVidia MCP51 High Definition Audio
hello, This worked fine in 2.6.23 but now the kernel no longer sees my audio controller. 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:10.1 0403: 10de:026c (rev a2) Let me know if I can provide more info or test patches. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.6.23-rc7 - 14 compile warnings
On Sat, 22 Sep 2007, WANG Cong wrote: > >Summary: > > CC mm/slub.o > >mm/slub.c: In function 'kfree': > >mm/slub.c:2491: warning: passing argument 3 of 'slab_free' discards > >qualifiers from pointer target type static void __slab_free(struct kmem_cache *s, struct page *page, void *x, void *addr) but .. void kfree(const void *x) void is not the same as const void. > > CC fs/autofs4/symlink.o > >fs/autofs4/symlink.c: In function 'autofs4_follow_link': > >fs/autofs4/symlink.c:18: warning: passing argument 2 of 'nd_set_link' > >discards qualifiers from pointer target type Once again ino->u.symlink is a const char and it's dropping the const. > > These two warnings are suspicious. Explicit casts are already there, how > they come out? Or gcc bugs? > gcc is perfectly justified when warning about dropping const. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.6.23-rc7 - 14 compile warnings
On Sat, 22 Sep 2007, WANG Cong wrote: Summary: CC mm/slub.o mm/slub.c: In function 'kfree': mm/slub.c:2491: warning: passing argument 3 of 'slab_free' discards qualifiers from pointer target type static void __slab_free(struct kmem_cache *s, struct page *page, void *x, void *addr) but .. void kfree(const void *x) void is not the same as const void. CC fs/autofs4/symlink.o fs/autofs4/symlink.c: In function 'autofs4_follow_link': fs/autofs4/symlink.c:18: warning: passing argument 2 of 'nd_set_link' discards qualifiers from pointer target type Once again ino-u.symlink is a const char and it's dropping the const. These two warnings are suspicious. Explicit casts are already there, how they come out? Or gcc bugs? gcc is perfectly justified when warning about dropping const. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.23-rc3: sysfs_remove_bin_file: bad dentry or inode or no such file: "descriptors"
On Sun, 2 Sep 2007, Andrew Morton wrote: > > On Tue, 14 Aug 2007 23:36:32 -0400 (EDT) Gerhard Mack <[EMAIL PROTECTED]> > > wrote: > > hello, > > > > Got this when I booted into 2.6.23-rc3: Let me know if more info is > > needed. > > > > Gerhard > > > > > > sysfs_remove_bin_file: bad dentry or inode or no such file: "descriptors" > > > > Call Trace: > > [] usb_remove_sysfs_dev_files+0x89/0x9d > > [] usb_unbind_device+0x15/0x19 > > [] __device_release_driver+0x8e/0xb0 > > [] device_release_driver+0x2c/0x44 > > [] bus_remove_device+0x6e/0x7d > > [] device_del+0x1ec/0x268 > > [] usb_disconnect+0xbc/0x149 > > [] hub_thread+0x3f8/0xba5 > > [] thread_return+0x57/0xdf > > [] autoremove_wake_function+0x0/0x2e > > [] hub_thread+0x0/0xba5 > > [] kthread+0x47/0x74 > > [] child_rip+0xa/0x12 > > [] flat_send_IPI_mask+0x0/0x4c > > [] kthread+0x0/0x74 > > [] child_rip+0x0/0x12 > > > > Is this still happening in 2.6.23-rc4 or later? 2.6.23-rc4 is fixed and so is 2.6.23-rc5. Thanks, Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.23-rc3: sysfs_remove_bin_file: bad dentry or inode or no such file: descriptors
On Sun, 2 Sep 2007, Andrew Morton wrote: On Tue, 14 Aug 2007 23:36:32 -0400 (EDT) Gerhard Mack [EMAIL PROTECTED] wrote: hello, Got this when I booted into 2.6.23-rc3: Let me know if more info is needed. Gerhard sysfs_remove_bin_file: bad dentry or inode or no such file: descriptors Call Trace: [80480117] usb_remove_sysfs_dev_files+0x89/0x9d [8047cf29] usb_unbind_device+0x15/0x19 [803f855e] __device_release_driver+0x8e/0xb0 [803f8953] device_release_driver+0x2c/0x44 [803f7e56] bus_remove_device+0x6e/0x7d [803f6641] device_del+0x1ec/0x268 [80477af3] usb_disconnect+0xbc/0x149 [804782c2] hub_thread+0x3f8/0xba5 [805e3463] thread_return+0x57/0xdf [80244f0b] autoremove_wake_function+0x0/0x2e [80477eca] hub_thread+0x0/0xba5 [80244df3] kthread+0x47/0x74 [8020c588] child_rip+0xa/0x12 [8021b96a] flat_send_IPI_mask+0x0/0x4c [80244dac] kthread+0x0/0x74 [8020c57e] child_rip+0x0/0x12 Is this still happening in 2.6.23-rc4 or later? 2.6.23-rc4 is fixed and so is 2.6.23-rc5. Thanks, Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.23-rc3: sysfs_remove_bin_file: bad dentry or inode or no such file: "descriptors"
hello, Got this when I booted into 2.6.23-rc3: Let me know if more info is needed. Gerhard sysfs_remove_bin_file: bad dentry or inode or no such file: "descriptors" Call Trace: [] usb_remove_sysfs_dev_files+0x89/0x9d [] usb_unbind_device+0x15/0x19 [] __device_release_driver+0x8e/0xb0 [] device_release_driver+0x2c/0x44 [] bus_remove_device+0x6e/0x7d [] device_del+0x1ec/0x268 [] usb_disconnect+0xbc/0x149 [] hub_thread+0x3f8/0xba5 [] thread_return+0x57/0xdf [] autoremove_wake_function+0x0/0x2e [] hub_thread+0x0/0xba5 [] kthread+0x47/0x74 [] child_rip+0xa/0x12 [] flat_send_IPI_mask+0x0/0x4c [] kthread+0x0/0x74 [] child_rip+0x0/0x12 -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.23-rc3: sysfs_remove_bin_file: bad dentry or inode or no such file: descriptors
hello, Got this when I booted into 2.6.23-rc3: Let me know if more info is needed. Gerhard sysfs_remove_bin_file: bad dentry or inode or no such file: descriptors Call Trace: [80480117] usb_remove_sysfs_dev_files+0x89/0x9d [8047cf29] usb_unbind_device+0x15/0x19 [803f855e] __device_release_driver+0x8e/0xb0 [803f8953] device_release_driver+0x2c/0x44 [803f7e56] bus_remove_device+0x6e/0x7d [803f6641] device_del+0x1ec/0x268 [80477af3] usb_disconnect+0xbc/0x149 [804782c2] hub_thread+0x3f8/0xba5 [805e3463] thread_return+0x57/0xdf [80244f0b] autoremove_wake_function+0x0/0x2e [80477eca] hub_thread+0x0/0xba5 [80244df3] kthread+0x47/0x74 [8020c588] child_rip+0xa/0x12 [8021b96a] flat_send_IPI_mask+0x0/0x4c [80244dac] kthread+0x0/0x74 [8020c57e] child_rip+0x0/0x12 -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please release a stable kernel Linux 3.0
On Wed, 27 Jun 2007, Zoltán HUBERT wrote: > I don't remember how it was during 2.4 and before, but I > find it very suspicious that SuSE and RedHat only provide > 2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't > trust 2.6.x to be a replacement to 2.6.y > > And as I understand it, this is (was ?) the whole point of > stable/development kernels. "We" can trust a newer stable > kernel to be a drop-in replacement for an older stable > kernel (from the same series), while development kernels > need time to stabilize with the new whizz-bang-pfouit stuff > that you all so nicely add. > > Are the good ol' days lost in nostalgia ? Lost? maybe. Improved on, defiantly so it's loss isn't a bad thing. The 2.4/2.5 split was, as far as I recall, a mess. 2.5 had too many changes to stabilize in any reasonable amount of time and 2.4 then needed new drivers and features to keep it from becoming obsolete. Back porting drivers without the needed infrastructure resulted in instabilities in the 2.4 branch. I recall one time where I needed a certain raid device working and not a single kernel had that driver working properly. 2.4.x oopsed in the driver after random intervals and the 2.5 kernel crashed in other places. Now development is broken into smaller stages that are easier to debug and made stable in shorter time. If I just need to update a kernel and don't need any new features and drivers I can just update to the next point release and I know it won't break anything. If I want new features I can update to the latest stable branch or the latest pre release but either way my stuff is more likely to work than I did back in the 2.5 days. I think people who keep demanding a return to the old development system forget how badly it sucked in the first place. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing.
Re: Please release a stable kernel Linux 3.0
On Wed, 27 Jun 2007, Zoltán HUBERT wrote: I don't remember how it was during 2.4 and before, but I find it very suspicious that SuSE and RedHat only provide 2.6.10 and 2.6.9 for their OS. It looks as if THEY didn't trust 2.6.x to be a replacement to 2.6.y And as I understand it, this is (was ?) the whole point of stable/development kernels. We can trust a newer stable kernel to be a drop-in replacement for an older stable kernel (from the same series), while development kernels need time to stabilize with the new whizz-bang-pfouit stuff that you all so nicely add. Are the good ol' days lost in nostalgia ? Lost? maybe. Improved on, defiantly so it's loss isn't a bad thing. The 2.4/2.5 split was, as far as I recall, a mess. 2.5 had too many changes to stabilize in any reasonable amount of time and 2.4 then needed new drivers and features to keep it from becoming obsolete. Back porting drivers without the needed infrastructure resulted in instabilities in the 2.4 branch. I recall one time where I needed a certain raid device working and not a single kernel had that driver working properly. 2.4.x oopsed in the driver after random intervals and the 2.5 kernel crashed in other places. Now development is broken into smaller stages that are easier to debug and made stable in shorter time. If I just need to update a kernel and don't need any new features and drivers I can just update to the next point release and I know it won't break anything. If I want new features I can update to the latest stable branch or the latest pre release but either way my stuff is more likely to work than I did back in the 2.5 days. I think people who keep demanding a return to the old development system forget how badly it sucked in the first place. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing.
Re: man-pages-2.54 is released
On Fri, 8 Jun 2007, Michael Kerrisk wrote: > I just released man-pages-2.54 > This may sound like a dumb question but since you just released man-pages-2.52 and man-pages-2.53 recently as one batch and now this one. What is the difference between the versions and how do I know wich to install? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: man-pages-2.54 is released
On Fri, 8 Jun 2007, Michael Kerrisk wrote: I just released man-pages-2.54 This may sound like a dumb question but since you just released man-pages-2.52 and man-pages-2.53 recently as one batch and now this one. What is the difference between the versions and how do I know wich to install? Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] SATA freeze
On Wed, 9 May 2007, Robert Hancock wrote: > Gerhard Mack wrote: > > On Wed, 9 May 2007, Jeff Garzik wrote: > > > Gerhard Mack wrote: > > > > May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 > > > > SErr > > > > 0x180 action 0x2 frozen > > > > May 9 14:51:35 mgerhard kernel: ata1.00: cmd > > > > 35/00:00:80:6d:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out > > > > May 9 14:51:35 mgerhard kernel: res > > > > 40/00:c8:68:65:c8/84:00:09:00:00/e0 Emask 0x4 (timeout) > > > > May 9 14:51:42 mgerhard kernel: ata1: port is slow to respond, please > > > > be > > > > patient (Status 0xd0) > > > > > > > > Anything I can do to figgure out what's causing this? > > You're showing various flags set in the SError register, which suggests you're > having SATA communication problems with the drive. A bad SATA cable or power > problems would be a strong possibility. > > It really would be nice if we decoded these things more usefully for the user > (same with the regular ATA errors, like drivers/ide does), but in general > SError showing up as non-zero is a bad thing: > > 0x40 = "Handshake error: When set to one, this bit indicates that one or > more R_ERR handshake response was received in response to frame transmission. > Such errors may be the result of a CRC error detected by the recipient, a > disparity or 10b/8b decoding error, or other error condition leading to a > negative handshake on a transmitted frame." > > 0x180 = "Link Sequence Error: When set to one, this bit indicates that one > or more Link state machine error conditions was encountered since the last > time this bit was cleared. The Link Layer state machine defines the conditions > under which the link layer detects an erroneous transition." > > and > > "Transport state transition error: When set to one, this bit indicates that an > error has occurred in the transition from one state to another within the > Transport layer since the last time this bit was cleared." Just out of curiosity how often is that bit cleared? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] SATA freeze
On Thu, 10 May 2007, Mikael Pettersson wrote: > Date: Thu, 10 May 2007 10:51:57 +0200 > From: Mikael Pettersson <[EMAIL PROTECTED]> > To: Gerhard Mack <[EMAIL PROTECTED]> > Cc: Jeff Garzik <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org > Subject: Re: [2.6.21.1] SATA freeze > > Gerhard Mack writes: > > On Wed, 9 May 2007, Jeff Garzik wrote: > > > Gerhard Mack wrote: > > > > May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 > SErr > > > > 0x180 action 0x2 frozen > > > > May 9 14:51:35 mgerhard kernel: ata1.00: cmd > > > > 35/00:00:80:6d:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out > > > > May 9 14:51:35 mgerhard kernel: res > > > > 40/00:c8:68:65:c8/84:00:09:00:00/e0 Emask 0x4 (timeout) > > > > May 9 14:51:42 mgerhard kernel: ata1: port is slow to respond, please > be > > > > patient (Status 0xd0) > > > > > > > > Anything I can do to figgure out what's causing this? > > > > > > Provide full lspci, dmesg, kernel config? > > > > > Done. > > Your second boot (warm or cold?) Warm boot. > > > May 9 14:43:07 mgerhard kernel: klogd 1.4.1#20, log source = /proc/kmsg > started. > > May 9 14:43:07 mgerhard kernel: Linux version 2.6.21.1 ([EMAIL > PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 > SMP PREEMPT Wed May 2 20:08:35 EDT 2007 > > May 9 14:43:07 mgerhard kernel: Command line: root=/dev/sda3 ro > > worked fine until ReiserFS's journal replay caused a single SATA exception: > > > May 9 14:43:07 mgerhard kernel: ReiserFS: sda3: There were 7 uncompleted > unlinks/truncates. Completed > > May 9 14:43:07 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 > SErr 0x40 action 0x2 > > May 9 14:43:07 mgerhard kernel: ata1.00: (BMDMA stat 0x25) > > May 9 14:43:07 mgerhard kernel: ata1.00: cmd > 35/00:58:20:4d:23/00:01:00:00:00/e0 tag 0 cdb 0x0 data 176128 out > > May 9 14:43:07 mgerhard kernel: res > 51/84:28:50:4d:23/84:01:00:00:00/e0 Emask 0x10 (ATA bus error) > > May 9 14:43:07 mgerhard kernel: ata1: soft resetting port > > May 9 14:43:07 mgerhard kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 > SControl 300) > > May 9 14:43:07 mgerhard kernel: ata1.00: configured for UDMA/100 > > May 9 14:43:07 mgerhard kernel: ata1: EH complete > > May 9 14:43:07 mgerhard kernel: SCSI device sda: 488397168 512-byte hdwr > sectors (250059 MB) > > Shortly thereafter you loaded a proprietary module Oops thought I killed that. > > > May 9 14:43:17 mgerhard kernel: nvidia: module license 'NVIDIA' taints > kernel. > > May 9 14:43:17 mgerhard kernel: ACPI: PCI Interrupt Link [APC7] enabled > at IRQ 16 > > May 9 14:43:17 mgerhard kernel: ACPI: PCI Interrupt :00:05.0[A] -> > Link [APC7] -> GSI 16 (level, low) -> IRQ 16 > > May 9 14:43:17 mgerhard kernel: PCI: Setting latency timer of device > :00:05.0 to 64 > > May 9 14:43:17 mgerhard kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel > Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 > > and immediately there's a large number of SATA exceptions: > > > May 9 14:44:37 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 > SErr 0x40 action 0x2 > > May 9 14:44:37 mgerhard kernel: ata1.00: (BMDMA stat 0x25) > > May 9 14:44:37 mgerhard kernel: ata1.00: cmd > 35/00:00:b0:53:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out > > May 9 14:44:37 mgerhard kernel: res > 51/84:60:50:56:c8/84:01:09:00:00/e0 Emask 0x10 (ATA bus error) > > May 9 14:44:37 mgerhard kernel: ata1: soft resetting port > > May 9 14:44:37 mgerhard kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 > SControl 300) > > May 9 14:44:37 mgerhard kernel: ata1.00: configured for UDMA/100 > (repeated) > > Please try a cold boot (so the HW is in a pristine state) without > ever loading the nvidia module. Cold boot cleared the drive problems. Nvidia loaded or not has no affect on it at this point. Thanks for the help. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] SATA freeze
On Thu, 10 May 2007, Mikael Pettersson wrote: Date: Thu, 10 May 2007 10:51:57 +0200 From: Mikael Pettersson [EMAIL PROTECTED] To: Gerhard Mack [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED], linux-kernel@vger.kernel.org Subject: Re: [2.6.21.1] SATA freeze Gerhard Mack writes: On Wed, 9 May 2007, Jeff Garzik wrote: Gerhard Mack wrote: May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x180 action 0x2 frozen May 9 14:51:35 mgerhard kernel: ata1.00: cmd 35/00:00:80:6d:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out May 9 14:51:35 mgerhard kernel: res 40/00:c8:68:65:c8/84:00:09:00:00/e0 Emask 0x4 (timeout) May 9 14:51:42 mgerhard kernel: ata1: port is slow to respond, please be patient (Status 0xd0) Anything I can do to figgure out what's causing this? Provide full lspci, dmesg, kernel config? Done. Your second boot (warm or cold?) Warm boot. May 9 14:43:07 mgerhard kernel: klogd 1.4.1#20, log source = /proc/kmsg started. May 9 14:43:07 mgerhard kernel: Linux version 2.6.21.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Wed May 2 20:08:35 EDT 2007 May 9 14:43:07 mgerhard kernel: Command line: root=/dev/sda3 ro worked fine until ReiserFS's journal replay caused a single SATA exception: May 9 14:43:07 mgerhard kernel: ReiserFS: sda3: There were 7 uncompleted unlinks/truncates. Completed May 9 14:43:07 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 May 9 14:43:07 mgerhard kernel: ata1.00: (BMDMA stat 0x25) May 9 14:43:07 mgerhard kernel: ata1.00: cmd 35/00:58:20:4d:23/00:01:00:00:00/e0 tag 0 cdb 0x0 data 176128 out May 9 14:43:07 mgerhard kernel: res 51/84:28:50:4d:23/84:01:00:00:00/e0 Emask 0x10 (ATA bus error) May 9 14:43:07 mgerhard kernel: ata1: soft resetting port May 9 14:43:07 mgerhard kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) May 9 14:43:07 mgerhard kernel: ata1.00: configured for UDMA/100 May 9 14:43:07 mgerhard kernel: ata1: EH complete May 9 14:43:07 mgerhard kernel: SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) Shortly thereafter you loaded a proprietary module Oops thought I killed that. May 9 14:43:17 mgerhard kernel: nvidia: module license 'NVIDIA' taints kernel. May 9 14:43:17 mgerhard kernel: ACPI: PCI Interrupt Link [APC7] enabled at IRQ 16 May 9 14:43:17 mgerhard kernel: ACPI: PCI Interrupt :00:05.0[A] - Link [APC7] - GSI 16 (level, low) - IRQ 16 May 9 14:43:17 mgerhard kernel: PCI: Setting latency timer of device :00:05.0 to 64 May 9 14:43:17 mgerhard kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9746 Fri Dec 15 10:19:35 PST 2006 and immediately there's a large number of SATA exceptions: May 9 14:44:37 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 May 9 14:44:37 mgerhard kernel: ata1.00: (BMDMA stat 0x25) May 9 14:44:37 mgerhard kernel: ata1.00: cmd 35/00:00:b0:53:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out May 9 14:44:37 mgerhard kernel: res 51/84:60:50:56:c8/84:01:09:00:00/e0 Emask 0x10 (ATA bus error) May 9 14:44:37 mgerhard kernel: ata1: soft resetting port May 9 14:44:37 mgerhard kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) May 9 14:44:37 mgerhard kernel: ata1.00: configured for UDMA/100 (repeated) Please try a cold boot (so the HW is in a pristine state) without ever loading the nvidia module. Cold boot cleared the drive problems. Nvidia loaded or not has no affect on it at this point. Thanks for the help. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] SATA freeze
On Wed, 9 May 2007, Robert Hancock wrote: Gerhard Mack wrote: On Wed, 9 May 2007, Jeff Garzik wrote: Gerhard Mack wrote: May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x180 action 0x2 frozen May 9 14:51:35 mgerhard kernel: ata1.00: cmd 35/00:00:80:6d:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out May 9 14:51:35 mgerhard kernel: res 40/00:c8:68:65:c8/84:00:09:00:00/e0 Emask 0x4 (timeout) May 9 14:51:42 mgerhard kernel: ata1: port is slow to respond, please be patient (Status 0xd0) Anything I can do to figgure out what's causing this? You're showing various flags set in the SError register, which suggests you're having SATA communication problems with the drive. A bad SATA cable or power problems would be a strong possibility. It really would be nice if we decoded these things more usefully for the user (same with the regular ATA errors, like drivers/ide does), but in general SError showing up as non-zero is a bad thing: 0x40 = Handshake error: When set to one, this bit indicates that one or more R_ERR handshake response was received in response to frame transmission. Such errors may be the result of a CRC error detected by the recipient, a disparity or 10b/8b decoding error, or other error condition leading to a negative handshake on a transmitted frame. 0x180 = Link Sequence Error: When set to one, this bit indicates that one or more Link state machine error conditions was encountered since the last time this bit was cleared. The Link Layer state machine defines the conditions under which the link layer detects an erroneous transition. and Transport state transition error: When set to one, this bit indicates that an error has occurred in the transition from one state to another within the Transport layer since the last time this bit was cleared. Just out of curiosity how often is that bit cleared? Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] SATA freeze
May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x180 action 0x2 frozen May 9 14:51:35 mgerhard kernel: ata1.00: cmd 35/00:00:80:6d:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out May 9 14:51:35 mgerhard kernel: res 40/00:c8:68:65:c8/84:00:09:00:00/e0 Emask 0x4 (timeout) May 9 14:51:42 mgerhard kernel: ata1: port is slow to respond, please be patient (Status 0xd0) Anything I can do to figgure out what's causing this? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] SATA freeze
May 9 14:51:35 mgerhard kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x180 action 0x2 frozen May 9 14:51:35 mgerhard kernel: ata1.00: cmd 35/00:00:80:6d:c8/00:04:09:00:00/e0 tag 0 cdb 0x0 data 524288 out May 9 14:51:35 mgerhard kernel: res 40/00:c8:68:65:c8/84:00:09:00:00/e0 Emask 0x4 (timeout) May 9 14:51:42 mgerhard kernel: ata1: port is slow to respond, please be patient (Status 0xd0) Anything I can do to figgure out what's causing this? Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
On Tue, 1 May 2007, Cabot, Mason B wrote: > Hello all, > > I've been testing the NAS performance of ext3/Openfiler 2.2 against > NTFS/WinXP and have found that NTFS significantly outperforms ext3 for > video workloads. The Windows CIFS client will attempt a poor-man's > pre-allocation of the file on the server by sending 1-byte writes at > 128K-byte strides, breaking block allocation on ext3 and leading to > fragmentation and poor performance. This will happen for many > applications (including iTunes) as the CIFS client issues these > pre-allocates under the application layer. > > I've posted a brief paper on Intel's OSS website > (http://softwarecommunity.intel.com/articles/eng/1259.htm). Please give > it a read and let me know what you think. In particular, I'd like to > arrive at the right place to fix this problem: is it in the filesystem, > VFS, or Samba? > > thanks, > Mason > Just out of curiosity do other filesystems(reiser, xfs) take the same performance hit? Gerjard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
On Tue, 1 May 2007, Cabot, Mason B wrote: Hello all, I've been testing the NAS performance of ext3/Openfiler 2.2 against NTFS/WinXP and have found that NTFS significantly outperforms ext3 for video workloads. The Windows CIFS client will attempt a poor-man's pre-allocation of the file on the server by sending 1-byte writes at 128K-byte strides, breaking block allocation on ext3 and leading to fragmentation and poor performance. This will happen for many applications (including iTunes) as the CIFS client issues these pre-allocates under the application layer. I've posted a brief paper on Intel's OSS website (http://softwarecommunity.intel.com/articles/eng/1259.htm). Please give it a read and let me know what you think. In particular, I'd like to arrive at the right place to fix this problem: is it in the filesystem, VFS, or Samba? thanks, Mason Just out of curiosity do other filesystems(reiser, xfs) take the same performance hit? Gerjard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] UidBind LSM 0.2
On Tue, 24 Apr 2007, Casey Schaufler wrote: > --- Gerhard Mack <[EMAIL PROTECTED]> wrote: > > > On Tue, 24 Apr 2007, Roberto De Ioris wrote: > > > > > Hi all, > > > > > > this is the second release for UidBind LSM: > > > > > > http://projects.unbit.it/uidbind/ > > > > > > UidBind allows call to bind() function only to the uid defined in a > > > configfs tree. > > > > > > It is now possible to specify different uid (for the same port) on > > > different ipv4 addresses: > > > > > > mkdir uidbind/8081 > > > mkdir uidbind/8081/192.168.1.17 > > > mkdir uidbind/8081/192.168.1.26 > > > echo 1017 > uidbind/8081/192.168.1.17/uid > > > echo 1026 > uidbind/8081/192.168.1.26/uid > > > > > > This version even fix some leek in version 0.1 > > > > > > Patch attached is still for vanilla 2.6.20.7 > > > > Is it possible to specify ranges as allowing everyone? Is it possible to > > allow multiple users acess to the same port? Can ports be allowed by > > group? > > If you're going to go beyond the simple owner access model it > probably makes sense to go all out, swipe the file system ACL > code and provide the whole nine yards of users, groups, and modes. > The only system that I know of that had socket ACLs was the 4.X > version of Trusted Irix, and socket ACLs were dropped in 5.0 because > they were unpopular. > > If you're daring you could propose that low number ports be treated > the same way as other ports, with the default ownership being root and > the default ACL allowing only root. ACL may be more complicated than needed when a simple GID addition would make this right about perfect. > > I really like the idea of this patch. It has the potential to solve a lot > > of my current administrative headachs. > > Putting access control on ports rather than sockets is a novel > approach. It is a lot simpler underneath and more consistant with > the way other object name spaces are treated. Indeed I'm fond of it's rather simple and very scriptable interface. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] UidBind LSM 0.2
On Tue, 24 Apr 2007, Roberto De Ioris wrote: > Hi all, > > this is the second release for UidBind LSM: > > http://projects.unbit.it/uidbind/ > > UidBind allows call to bind() function only to the uid defined in a > configfs tree. > > It is now possible to specify different uid (for the same port) on > different ipv4 addresses: > > mkdir uidbind/8081 > mkdir uidbind/8081/192.168.1.17 > mkdir uidbind/8081/192.168.1.26 > echo 1017 > uidbind/8081/192.168.1.17/uid > echo 1026 > uidbind/8081/192.168.1.26/uid > > This version even fix some leek in version 0.1 > > Patch attached is still for vanilla 2.6.20.7 Is it possible to specify ranges as allowing everyone? Is it possible to allow multiple users acess to the same port? Can ports be allowed by group? I really like the idea of this patch. It has the potential to solve a lot of my current administrative headachs. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] UidBind LSM 0.2
On Tue, 24 Apr 2007, Roberto De Ioris wrote: Hi all, this is the second release for UidBind LSM: http://projects.unbit.it/uidbind/ UidBind allows call to bind() function only to the uid defined in a configfs tree. It is now possible to specify different uid (for the same port) on different ipv4 addresses: mkdir uidbind/8081 mkdir uidbind/8081/192.168.1.17 mkdir uidbind/8081/192.168.1.26 echo 1017 uidbind/8081/192.168.1.17/uid echo 1026 uidbind/8081/192.168.1.26/uid This version even fix some leek in version 0.1 Patch attached is still for vanilla 2.6.20.7 Is it possible to specify ranges as allowing everyone? Is it possible to allow multiple users acess to the same port? Can ports be allowed by group? I really like the idea of this patch. It has the potential to solve a lot of my current administrative headachs. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] UidBind LSM 0.2
On Tue, 24 Apr 2007, Casey Schaufler wrote: --- Gerhard Mack [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007, Roberto De Ioris wrote: Hi all, this is the second release for UidBind LSM: http://projects.unbit.it/uidbind/ UidBind allows call to bind() function only to the uid defined in a configfs tree. It is now possible to specify different uid (for the same port) on different ipv4 addresses: mkdir uidbind/8081 mkdir uidbind/8081/192.168.1.17 mkdir uidbind/8081/192.168.1.26 echo 1017 uidbind/8081/192.168.1.17/uid echo 1026 uidbind/8081/192.168.1.26/uid This version even fix some leek in version 0.1 Patch attached is still for vanilla 2.6.20.7 Is it possible to specify ranges as allowing everyone? Is it possible to allow multiple users acess to the same port? Can ports be allowed by group? If you're going to go beyond the simple owner access model it probably makes sense to go all out, swipe the file system ACL code and provide the whole nine yards of users, groups, and modes. The only system that I know of that had socket ACLs was the 4.X version of Trusted Irix, and socket ACLs were dropped in 5.0 because they were unpopular. If you're daring you could propose that low number ports be treated the same way as other ports, with the default ownership being root and the default ACL allowing only root. ACL may be more complicated than needed when a simple GID addition would make this right about perfect. I really like the idea of this patch. It has the potential to solve a lot of my current administrative headachs. Putting access control on ports rather than sockets is a novel approach. It is a lot simpler underneath and more consistant with the way other object name spaces are treated. Indeed I'm fond of it's rather simple and very scriptable interface. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] UidBind LSM 0.1
On Mon, 23 Apr 2007, Roberto De Ioris wrote: > Hi all, > this is a very simple module that allows bind() to tcp/udp port (>=1024) > only for the uids defined in a configfs tree. > > It is a first version, it only works for PF_INET sockets and makes no > difference between tcp and udp (i am working on this) > > For (little) more info see > > http://projects.unbit.it/uidbind/ > > Patch attached is for vanilla 2.6.20.7 Is it possible to lock a range of ports to a uid? Also, is it possible to lock a uid to one ip address? For example usera can only bind to 10.0.0.23 while userb can only bind to 10.0.0.24. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] UidBind LSM 0.1
On Mon, 23 Apr 2007, Roberto De Ioris wrote: Hi all, this is a very simple module that allows bind() to tcp/udp port (=1024) only for the uids defined in a configfs tree. It is a first version, it only works for PF_INET sockets and makes no difference between tcp and udp (i am working on this) For (little) more info see http://projects.unbit.it/uidbind/ Patch attached is for vanilla 2.6.20.7 Is it possible to lock a range of ports to a uid? Also, is it possible to lock a uid to one ip address? For example usera can only bind to 10.0.0.23 while userb can only bind to 10.0.0.24. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Stop pmac_zilog from abusing 8250's device numbers.
Sometimes it's not the speed it's the cost.. The best I've ever done is 5.5 interfaces per u/ Although with a better motherboard and case it might have been different. http://innerfire.net/pics/projects/21portfirewall_2.jpg (assigns each port it's ip range and blocks any address not assigned to that port) On Thu, 12 Apr 2007, Roland Dreier wrote: > Date: Thu, 12 Apr 2007 08:34:40 -0700 > From: Roland Dreier <[EMAIL PROTECTED]> > To: Benny Amorsen <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. > > > Indeed, port density is disappointingly poor in modern servers. Do you > > know any with more than 14 ports per U? (That's an MBX 1U server with > > 8 on-board and a 6-port expansion). > > If you really need a ton of ports you could probably build a 1U server > with 2 * 2-port 10gig NICs, and use VLAN-capable switches with 10gig > and 1gig ports to fan out each 10gig link from your server to 10 1-gig > ports. That would get you 40 ports of 1-gig from each server (plus > whatever the server has on board). > > - R. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Stop pmac_zilog from abusing 8250's device numbers.
Sometimes it's not the speed it's the cost.. The best I've ever done is 5.5 interfaces per u/ Although with a better motherboard and case it might have been different. http://innerfire.net/pics/projects/21portfirewall_2.jpg (assigns each port it's ip range and blocks any address not assigned to that port) On Thu, 12 Apr 2007, Roland Dreier wrote: Date: Thu, 12 Apr 2007 08:34:40 -0700 From: Roland Dreier [EMAIL PROTECTED] To: Benny Amorsen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PATCH] Stop pmac_zilog from abusing 8250's device numbers. Indeed, port density is disappointingly poor in modern servers. Do you know any with more than 14 ports per U? (That's an MBX 1U server with 8 on-board and a 6-port expansion). If you really need a ton of ports you could probably build a 1U server with 2 * 2-port 10gig NICs, and use VLAN-capable switches with 10gig and 1gig ports to fan out each 10gig link from your server to 10 1-gig ports. That would get you 40 ports of 1-gig from each server (plus whatever the server has on board). - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Stop pmac_zilog from abusing 8250's device numbers.
On Wed, 4 Apr 2007, Alan Cox wrote: > You don't get machines with 64 ethernet ports on add-in cards. There are > good reasons for the naming schemes in use. If they made them I'd build one. http://innerfire.net/pics/projects/21portfirewall_2.jpg Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Stop pmac_zilog from abusing 8250's device numbers.
On Wed, 4 Apr 2007, Alan Cox wrote: You don't get machines with 64 ethernet ports on add-in cards. There are good reasons for the naming schemes in use. If they made them I'd build one. http://innerfire.net/pics/projects/21portfirewall_2.jpg Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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-rc5] forcedeth slow ifup.
I'm not sure what's causing it but the onboard ethernet is taking a rather long time to come up.. the old nforce board worked fine and any other card is fast. mgerhard:~# time ifup eth0 real0m12.397s user0m0.214s sys 0m0.160s eth0 Link encap:Ethernet HWaddr 00:18:F3:EB:DF:88 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::218:f3ff:feeb:df88/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:162472 errors:0 dropped:0 overruns:0 frame:0 TX packets:176386 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:82252621 (78.4 MiB) TX bytes:30913296 (29.4 MiB) Interrupt:23 Base address:0x2000 lspci shows: 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-rc5] forcedeth slow ifup.
I'm not sure what's causing it but the onboard ethernet is taking a rather long time to come up.. the old nforce board worked fine and any other card is fast. mgerhard:~# time ifup eth0 real0m12.397s user0m0.214s sys 0m0.160s eth0 Link encap:Ethernet HWaddr 00:18:F3:EB:DF:88 inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::218:f3ff:feeb:df88/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:162472 errors:0 dropped:0 overruns:0 frame:0 TX packets:176386 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:82252621 (78.4 MiB) TX bytes:30913296 (29.4 MiB) Interrupt:23 Base address:0x2000 lspci shows: 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: > Date: Wed, 28 Feb 2007 18:21:48 -0600 > From: Robert Hancock <[EMAIL PROTECTED]> > To: Gerhard Mack <[EMAIL PROTECTED]> > Cc: linux-kernel , > Charles Shannon Hendrix <[EMAIL PROTECTED]> > Subject: Re: 2.6.20 SATA error > > Gerhard Mack wrote: > > > > Sorry for the false alarm, > > > There is one thing that seems odd, if you do have an nForce4 chipset, the > > > kernel should be running the SATA controller in ADMA mode in 2.6.20, but > > > it > > > doesn't seem like it is from your dmesg output. Can you post the output of > > > "lspci -vvn"? Also what kind of motherboard is that? > > > > > Sure thing. It's an Asus m2npv-vm. > > Ah, that would be why, it's not one of the original nForce4 (CK804/MCP04) > chipsets, it's the newer nForce 430 (MCP51) chipset which doesn't support > ADMA. NVidia said they'd be sending some patches to allow NCQ support on MCP51 > and MCP61 chipsets back in October, but I haven't seen any, or information > required to implement same.. fun stuff.. I guess it's back to trying to get the onboard ethernet card to work in debian. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: > Gerhard Mack wrote: > > On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote: > > > > > On Wed, 28 Feb 2007 13:25:00 -0500 (EST) > > > Gerhard Mack <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > In another thread, I think they were saying it was either a SATA > > > > > chipset > > > > > driver bug, or a problem in libata core. > > > > I also have an nforce4. > > > On another mailing list, someone with an Intel chipset is reporting the > > > same > > > problem, and also that others without nforce chipsets are seeing it. > > > > I was reaching inside my computer to check something and heared the thing > > click and got the same error message. > > > > Turns out the adaptor that goes between SATA drive and the old style power > > connector was loose on the drive side. Doesn't seem to me like it was very > > snug fitting to begin with. I changed it to one of the proper SATA > > connectors comming off the power supply and it doesn't do that anymore. > > > > Sorry for the false alarm, > > There is one thing that seems odd, if you do have an nForce4 chipset, the > kernel should be running the SATA controller in ADMA mode in 2.6.20, but it > doesn't seem like it is from your dmesg output. Can you post the output of > "lspci -vvn"? Also what kind of motherboard is that? > Sure thing. It's an Asus m2npv-vm. Gerhard mgerhard:/home/gmack# lspci -vvn 00:00.0 0500: 10de:02f0 (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR+ TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: 10de: Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: fee0300c Data: 4141 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [100] Virtual Channel 00:03.0 0604: 10de:02fd (rev a1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: 10de: Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: fee0300c Data: 4149 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, Power
solved Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote: > On Wed, 28 Feb 2007 13:25:00 -0500 (EST) > Gerhard Mack <[EMAIL PROTECTED]> wrote: > > > > > In another thread, I think they were saying it was either a SATA chipset > > > driver bug, or a problem in libata core. > > > > I also have an nforce4. > > On another mailing list, someone with an Intel chipset is reporting the same > problem, and also that others without nforce chipsets are seeing it. I was reaching inside my computer to check something and heared the thing click and got the same error message. Turns out the adaptor that goes between SATA drive and the old style power connector was loose on the drive side. Doesn't seem to me like it was very snug fitting to begin with. I changed it to one of the proper SATA connectors comming off the power supply and it doesn't do that anymore. Sorry for the false alarm, Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote: > On Wed, 28 Feb 2007 07:40:23 -0500 (EST) > Gerhard Mack <[EMAIL PROTECTED]> wrote: > > > hello, > > > > Can someone tell me what this means? > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen > > ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 > > out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > ata1: port is slow to respond, please be patient (Status 0xd0) > > ata1: port failed to respond (30 secs, Status 0xd0) > > ata1: soft resetting port > > ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > ata1.00: configured for UDMA/100 > > I am fairly certain this is a bug in the 2.6.20 kernel. > > I never see it in 2.6.19*, just 2.6.20. > > It is some kind of but in the SATA code paths, or at least that's all it > appears to affect on my system. > > What chipset do you have? > > I have an nforce4 chipset. > > In another thread, I think they were saying it was either a SATA chipset > driver bug, or a problem in libata core. I also have an nforce4. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Tomas Carnecky wrote: > Gerhard Mack wrote: > > ata1.00: configured for UDMA/100 > > [...] > > ata1.00: configured for UDMA/66 > > [...] > > ata1.00: configured for UDMA/44 > > [...] > > ata1.00: configured for UDMA/33 > > [...] > > ata1.00: configured for UDMA/25 > > [...] > > ata1.00: configured for UDMA/16 > > [...] > > ata1.00: configured for PIO4 > > I have the same problem, though it appears randomly. It seems like the chances > for this happening are bigger if I do heavy disk I/O. The only way to fix that > is to shut down the computer and wait a few seconds before rebooting (if I > don't wait, the problem doesn't go away). I bought new harddrives, so it's > most likely not caused by the drives, I also tried putting the drives onto a > different controller (I have four on-board SATA controller and two > harddrives), that didn't help either, so I suspect its the cable - SATA cables > are very error-prone, I don't trust them as they don't hold that tightly in Well that's the strange thing.. I've done heavy I/O on this with no trouble. This happened overnight when my system should have been mostly idle Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: > Gerhard Mack wrote: > > hello, > > Can someone tell me what this means? > > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen > > ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 > > out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > ata1: port is slow to respond, please be patient (Status 0xd0) > > ata1: port failed to respond (30 secs, Status 0xd0) > > ata1: soft resetting port > > ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > ata1.00: configured for UDMA/100 > > ata1: EH complete > > SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) > > sda: Write Protect is off > > sda: Mode Sense: 00 3a 00 00 > > SCSI device sda: write cache: enabled, read cache: enabled, doesn't support > > DPO > > or FUA > > Some command timed out, apparently. From this one can't easily say why. Please > send full dmesg. > Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #10 SMP PREEMPT Mon Feb 26 14:48:53 EST 2007 Command line: root=/dev/sda3 ro BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3def (usable) BIOS-e820: 3def - 3def3000 (ACPI NVS) BIOS-e820: 3def3000 - 3df0 (ACPI data) BIOS-e820: 3e00 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 253680) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP (v002 Nvidia) @ 0x000f7560 ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3def30c0 ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb3c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3defb5c0 ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3defb840 ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb8c0 ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb500 ACPI: DSDT (v001 NVIDIA ASUSACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 253680) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 253680 On node 0 totalpages: 253583 DMA zone: 56 pages used for memmap DMA zone: 1831 pages reserved DMA zone: 2112 pages, LIFO batch:0 DMA32 zone: 3412 pages used for memmap DMA32 zone: 246172 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 5000 (gap: 4000:a000) PERCPU: Allocating 33152 bytes of per cpu data Built 1 zonelists. Total pages: 248284 Kernel command line: root=/dev/sda3 ro Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ fa9c00 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 991204k/1014720k available (3834k kernel code, 22888k reserved, 2637k data, 256k init) Calibrating de
2.6.20 SATA error
hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.20 SATA error
hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: Gerhard Mack wrote: hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Some command timed out, apparently. From this one can't easily say why. Please send full dmesg. Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #10 SMP PREEMPT Mon Feb 26 14:48:53 EST 2007 Command line: root=/dev/sda3 ro BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3def (usable) BIOS-e820: 3def - 3def3000 (ACPI NVS) BIOS-e820: 3def3000 - 3df0 (ACPI data) BIOS-e820: 3e00 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 253680) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP (v002 Nvidia) @ 0x000f7560 ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3def30c0 ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb3c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3defb5c0 ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3defb840 ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb8c0 ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3defb500 ACPI: DSDT (v001 NVIDIA ASUSACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 253680) 1 entries of 256 used Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 253680 On node 0 totalpages: 253583 DMA zone: 56 pages used for memmap DMA zone: 1831 pages reserved DMA zone: 2112 pages, LIFO batch:0 DMA32 zone: 3412 pages used for memmap DMA32 zone: 246172 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 5000 (gap: 4000:a000) PERCPU: Allocating 33152 bytes of per cpu data Built 1 zonelists. Total pages: 248284 Kernel command line: root=/dev/sda3 ro Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ fa9c00 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 991204k/1014720k available (3834k kernel code, 22888k reserved, 2637k data, 256k init) Calibrating delay using timer specific routine.. 4413.54 BogoMIPS (lpj=2206772) Security Framework v1.0.0 initialized Capability LSM initialized Failure registering Root Plug module with the kernel Failure
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Tomas Carnecky wrote: Gerhard Mack wrote: ata1.00: configured for UDMA/100 [...] ata1.00: configured for UDMA/66 [...] ata1.00: configured for UDMA/44 [...] ata1.00: configured for UDMA/33 [...] ata1.00: configured for UDMA/25 [...] ata1.00: configured for UDMA/16 [...] ata1.00: configured for PIO4 I have the same problem, though it appears randomly. It seems like the chances for this happening are bigger if I do heavy disk I/O. The only way to fix that is to shut down the computer and wait a few seconds before rebooting (if I don't wait, the problem doesn't go away). I bought new harddrives, so it's most likely not caused by the drives, I also tried putting the drives onto a different controller (I have four on-board SATA controller and two harddrives), that didn't help either, so I suspect its the cable - SATA cables are very error-prone, I don't trust them as they don't hold that tightly in Well that's the strange thing.. I've done heavy I/O on this with no trouble. This happened overnight when my system should have been mostly idle Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote: On Wed, 28 Feb 2007 07:40:23 -0500 (EST) Gerhard Mack [EMAIL PROTECTED] wrote: hello, Can someone tell me what this means? ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x40 action 0x2 frozen ata1.00: cmd 35/00:00:40:a6:23/00:04:00:00:00/e0 tag 0 cdb 0x0 data 524288 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: port is slow to respond, please be patient (Status 0xd0) ata1: port failed to respond (30 secs, Status 0xd0) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/100 I am fairly certain this is a bug in the 2.6.20 kernel. I never see it in 2.6.19*, just 2.6.20. It is some kind of but in the SATA code paths, or at least that's all it appears to affect on my system. What chipset do you have? I have an nforce4 chipset. In another thread, I think they were saying it was either a SATA chipset driver bug, or a problem in libata core. I also have an nforce4. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
solved Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote: On Wed, 28 Feb 2007 13:25:00 -0500 (EST) Gerhard Mack [EMAIL PROTECTED] wrote: In another thread, I think they were saying it was either a SATA chipset driver bug, or a problem in libata core. I also have an nforce4. On another mailing list, someone with an Intel chipset is reporting the same problem, and also that others without nforce chipsets are seeing it. I was reaching inside my computer to check something and heared the thing click and got the same error message. Turns out the adaptor that goes between SATA drive and the old style power connector was loose on the drive side. Doesn't seem to me like it was very snug fitting to begin with. I changed it to one of the proper SATA connectors comming off the power supply and it doesn't do that anymore. Sorry for the false alarm, Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: Gerhard Mack wrote: On Wed, 28 Feb 2007, Charles Shannon Hendrix wrote: On Wed, 28 Feb 2007 13:25:00 -0500 (EST) Gerhard Mack [EMAIL PROTECTED] wrote: In another thread, I think they were saying it was either a SATA chipset driver bug, or a problem in libata core. I also have an nforce4. On another mailing list, someone with an Intel chipset is reporting the same problem, and also that others without nforce chipsets are seeing it. I was reaching inside my computer to check something and heared the thing click and got the same error message. Turns out the adaptor that goes between SATA drive and the old style power connector was loose on the drive side. Doesn't seem to me like it was very snug fitting to begin with. I changed it to one of the proper SATA connectors comming off the power supply and it doesn't do that anymore. Sorry for the false alarm, There is one thing that seems odd, if you do have an nForce4 chipset, the kernel should be running the SATA controller in ADMA mode in 2.6.20, but it doesn't seem like it is from your dmesg output. Can you post the output of lspci -vvn? Also what kind of motherboard is that? Sure thing. It's an Asus m2npv-vm. Gerhard mgerhard:/home/gmack# lspci -vvn 00:00.0 0500: 10de:02f0 (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Command: BaseUnitID=0 UnitCnt=15 MastHost- DefDir- DUL- Link Control 0: CFlE+ CST- CFE- LkFail- Init+ EOC- TXO- CRCErr=0 IsocEn- LSEn- ExtCTL- 64b- Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn- Link Control 1: CFlE+ CST- CFE- LkFail- Init+ EOC- TXO- CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b- Link Config 1: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn- Revision ID: 1.03 Link Frequency 0: 1.0GHz Link Error 0: Prot- Ovfl- EOC- CTLTm- Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+ 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend- Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD- Link Frequency 1: 800MHz Link Error 1: Prot- Ovfl- EOC- CTLTm- Link Frequency Capability 1: 200MHz+ 300MHz+ 400MHz+ 500MHz+ 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend- Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE- Prefetchable memory behind bridge Upper: 00-00 Bus Number: 00 Capabilities: [e0] HyperTransport: MSI Mapping 00:00.1 0500: 10de:02fa (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR+ PERR- 00:00.2 0500: 10de:02fe (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.3 0500: 10de:02f8 (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.4 0500: 10de:02f9 (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 00:00.5 0500: 10de:02ff (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [44] #00 [00fe] Capabilities: [fc] #00 [] 00:00.6 0500: 10de:027f (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- 00:00.7 0500: 10de:027e (rev a2) Subsystem: 1043:81c0 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort
Re: 2.6.20 SATA error
On Wed, 28 Feb 2007, Robert Hancock wrote: Date: Wed, 28 Feb 2007 18:21:48 -0600 From: Robert Hancock [EMAIL PROTECTED] To: Gerhard Mack [EMAIL PROTECTED] Cc: linux-kernel linux-kernel@vger.kernel.org, Charles Shannon Hendrix [EMAIL PROTECTED] Subject: Re: 2.6.20 SATA error Gerhard Mack wrote: Sorry for the false alarm, There is one thing that seems odd, if you do have an nForce4 chipset, the kernel should be running the SATA controller in ADMA mode in 2.6.20, but it doesn't seem like it is from your dmesg output. Can you post the output of lspci -vvn? Also what kind of motherboard is that? Sure thing. It's an Asus m2npv-vm. Ah, that would be why, it's not one of the original nForce4 (CK804/MCP04) chipsets, it's the newer nForce 430 (MCP51) chipset which doesn't support ADMA. NVidia said they'd be sending some patches to allow NCQ support on MCP51 and MCP61 chipsets back in October, but I haven't seen any, or information required to implement same.. fun stuff.. I guess it's back to trying to get the onboard ethernet card to work in debian. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.20 trouble with Nvidia MCP51 Ethernet Controller
hello, I just got a new motherboard with an MCP51. The kernel detects it but then I have no eth0 device. from lspci: 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) dmesg shows: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59. ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 ACPI: PCI Interrupt :00:14.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 23 PCI: Setting latency timer of device :00:14.0 to 64 forcedeth: using HIGHDMA eth0: forcedeth.c: subsystem: 01043:816a bound to :00:14.0 mgerhard:~# ifup eth0 SIOCSIFADDR: No such device eth0: ERROR while getting interface flags: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device eth0: ERROR while getting interface flags: No such device eth0: ERROR while getting interface flags: No such device Failed to bring up eth0. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.20 trouble with Nvidia MCP51 Ethernet Controller
hello, I just got a new motherboard with an MCP51. The kernel detects it but then I have no eth0 device. from lspci: 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) dmesg shows: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59. ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 ACPI: PCI Interrupt :00:14.0[A] - Link [APCH] - GSI 23 (level, low) - IRQ 23 PCI: Setting latency timer of device :00:14.0 to 64 forcedeth: using HIGHDMA eth0: forcedeth.c: subsystem: 01043:816a bound to :00:14.0 mgerhard:~# ifup eth0 SIOCSIFADDR: No such device eth0: ERROR while getting interface flags: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device eth0: ERROR while getting interface flags: No such device eth0: ERROR while getting interface flags: No such device Failed to bring up eth0. -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK new drivers without proper power management?
On Sun, 11 Feb 2007, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: > > Many people also have Linux on their notebooks, but as a dual-boot. You > read the word ? "dual-boot". It means that they cleanly shutdown their > system every time they don't use it anymore, and they won't know what > OS they'll use next time. Please tell me your joking. Linux' crappy suspend support is a common reason people give me for not wanting Linux anywhere near their laptops. I have a single boot laptop that's somewhat of a mobile debugging station that needs Linux and I absolutely hate it. Right now my laptop takes far too long to boot and even if it didn't I wish I could suspend. I'm actually a huge Linux fan.. I use it exclusively on my server and on my PC but if I get another laptop I will probably run something else on it. Linux is just too annoying for that use. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK new drivers without proper power management?
On Sun, 11 Feb 2007, Willy Tarreau wrote: On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: Many people also have Linux on their notebooks, but as a dual-boot. You read the word ? dual-boot. It means that they cleanly shutdown their system every time they don't use it anymore, and they won't know what OS they'll use next time. Please tell me your joking. Linux' crappy suspend support is a common reason people give me for not wanting Linux anywhere near their laptops. I have a single boot laptop that's somewhat of a mobile debugging station that needs Linux and I absolutely hate it. Right now my laptop takes far too long to boot and even if it didn't I wish I could suspend. I'm actually a huge Linux fan.. I use it exclusively on my server and on my PC but if I get another laptop I will probably run something else on it. Linux is just too annoying for that use. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Ingo Oeser wrote: > On Monday, 5. February 2007, Linus Torvalds wrote: > > So thank God for the few selects we have, and we should add a whole lot > > more! > > But "select" is not fine grained enough. > > I would like to have "require", "recommend", "suggest" for feature A. > > require X > does not work without X, but X is way down the tree > e.g. ext3 and block device or how select currently is intended > > recommend X > it is usable but uncomfortable without X, enabled per default > e.g. firewalling recommends connection tracking support > or NAT recommends all NAT helpers > > suggest X > many people use A together with X, > so you might be interested in enabling it, but I disabled it > per default unless you said "featuritis mode" before. > e.g. highmem and SMP or a network driver and NAPI. > > That is what the Debian/Ubuntu package management does and maybe other too. > And this also gives us new keywords to replace select with, > so migration is doable :-) > > This would also make "EMBEDDED" superflous, because it would just mean > "disable anything not required". > > And this would enable an individual tree for the users current configuration > problem instead of a global one. I think "package manager" is the best possible way to think about this problem. I can't tell you how often I've wished the kernel config process behaved like apt and just prompted me with a list of things it would need to enable to allow me to use the option and ask me if I still want to do it. The reverse when I try and remove something important would be good too just ask me if I really want to remove all those as well. A functional equivelant of deborphan would be cool too. Just run it and have it tell me what is enabled that no devices depend on. The config system is nasty even for power users. There is a fun part of the netfilter code where I find myself having to enable all from one menu, go to the next menu down enable everything and then go back to the first menu. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, 5 Feb 2007, Ingo Oeser wrote: On Monday, 5. February 2007, Linus Torvalds wrote: So thank God for the few selects we have, and we should add a whole lot more! But select is not fine grained enough. I would like to have require, recommend, suggest for feature A. require X does not work without X, but X is way down the tree e.g. ext3 and block device or how select currently is intended recommend X it is usable but uncomfortable without X, enabled per default e.g. firewalling recommends connection tracking support or NAT recommends all NAT helpers suggest X many people use A together with X, so you might be interested in enabling it, but I disabled it per default unless you said featuritis mode before. e.g. highmem and SMP or a network driver and NAPI. That is what the Debian/Ubuntu package management does and maybe other too. And this also gives us new keywords to replace select with, so migration is doable :-) This would also make EMBEDDED superflous, because it would just mean disable anything not required. And this would enable an individual tree for the users current configuration problem instead of a global one. I think package manager is the best possible way to think about this problem. I can't tell you how often I've wished the kernel config process behaved like apt and just prompted me with a list of things it would need to enable to allow me to use the option and ask me if I still want to do it. The reverse when I try and remove something important would be good too just ask me if I really want to remove all those as well. A functional equivelant of deborphan would be cool too. Just run it and have it tell me what is enabled that no devices depend on. The config system is nasty even for power users. There is a fun part of the netfilter code where I find myself having to enable all from one menu, go to the next menu down enable everything and then go back to the first menu. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] radeonfb: add support for newer cards
On Tue, 2 Jan 2007, Luca wrote: > Date: Tue, 2 Jan 2007 01:38:17 +0100 > From: Luca <[EMAIL PROTECTED]> > To: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Cc: Andrew Morton <[EMAIL PROTECTED]>, Solomon Peachy <[EMAIL PROTECTED]>, > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > Subject: Re: [PATCH] radeonfb: add support for newer cards > > On 1/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-01-01 at 22:44 +0100, Luca Tettamanti wrote: > > > Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto: > > > > Hi Ben, Andrew, > > > > I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20. > > > > The patch adds support for newer Radeon cards and is mainly based on > > > > X.Org code. > > > > > > And - for an easier review - this is the diff between > > > radeonfb-atom-2.6.19-v6a.diff from Solomon and my patch (whitespace-only > > > changes not included). > > > > Ah good, what I was asking for :-) I'll try to get a new patch combining > > everything out asap. > > Great, I didn't know you were working on this, I feared that the patch > had been forgotten. > I've a X850 (R480) here, feel free to send me any patch for testing. > > Luca Is there a list of cards this adds support for? I'm waiting on support for the X1600 Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] radeonfb: add support for newer cards
On Tue, 2 Jan 2007, Luca wrote: Date: Tue, 2 Jan 2007 01:38:17 +0100 From: Luca [EMAIL PROTECTED] To: Benjamin Herrenschmidt [EMAIL PROTECTED] Cc: Andrew Morton [EMAIL PROTECTED], Solomon Peachy [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Subject: Re: [PATCH] radeonfb: add support for newer cards On 1/2/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Mon, 2007-01-01 at 22:44 +0100, Luca Tettamanti wrote: Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto: Hi Ben, Andrew, I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20. The patch adds support for newer Radeon cards and is mainly based on X.Org code. And - for an easier review - this is the diff between radeonfb-atom-2.6.19-v6a.diff from Solomon and my patch (whitespace-only changes not included). Ah good, what I was asking for :-) I'll try to get a new patch combining everything out asap. Great, I didn't know you were working on this, I feared that the patch had been forgotten. I've a X850 (R480) here, feel free to send me any patch for testing. Luca Is there a list of cards this adds support for? I'm waiting on support for the X1600 Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat, 16 Dec 2006, Dave Jones wrote: > On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote: > > > Anything else, you have to make some really scary decisions. Can a judge > > decide that a binary module is a derived work even though you didn't > > actually use any code? The real answer is: HELL YES. It's _entirely_ > > possible that a judge would find NVidia and ATI in violation of the GPLv2 > > with their modules. > > ATI in particular, I'm amazed their lawyers OK'd stuff like.. > > +ifdef STANDALONE > MODULE_LICENSE(GPL); > +endif > > This a paraphrased diff, it's been a while since I've seen it. > It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko, > but the usual use case is that it's built-in to fglrx.ko, which sounds > incredibly dubious. > > Now, AGPGART has a murky past wrt licenses. It initally was imported > into the tree with the license "GPL plus additional rights". > Nowhere was it actually documented what those rights were, but I'm > fairly certain it wasn't to enable nonsense like the above. > As it came from the XFree86 folks, it's more likely they really meant > "Dual GPL/MIT" or similar. > > When I took over, any new code I wrote I explicitly set out to mark as GPL > code, as my modifications weren't being contributed back to X, they were > going back to the Linux kernel. ATI took those AGPv3 modifications from > a 2.5 kernel, backported them to their 2.4 driver, and when time came > to do a 2.6 driver, instead of doing the sensible thing and dropping > them in favour of using the kernel AGP driver, they chose to forward > port their unholy abomination to 2.6. > It misses so many fixes (and introduces a number of other problems) > that its just unfunny. > > The thing that really ticks me off though is the free support ATI seem > to think they're entitled to. I've had end-users emailing me > "I asked ATI about this crash I've been seeing with fglrx, and they > asked me to mail you". > > I invest my time into improving free drivers. When companies start > expecting me to debug their part binary garbage mixed with license > violations, frankly, I think they're taking the piss. > > A year and a half ago, I met an ATI engineer at OLS, who told me they > were going to 'resolve this'. I'm still waiting. > I live in hope that the AMD buyout will breathe some sanity into ATI. > Then again, I've only a limited supply of optimism. You would think ATI's steaming pile of crap would be a good reason for them to give up on the whole binary module thing and just release specs so someone else can write a decent driver. I made the mistake of purchasing an ATI X1600. No open kernel driver.. no open X driver. The ATI drivers don't even complile on amd64 on any recent kernel and their X drivers are prone to random screen corruption that requires nothing less than a full reboot to clear. IMO let those morons keep writing themselves into a corner with this crud and then perhapse they will see for themselves that binary modules are a horribly bad idea instead of having someone else to blame when this whole thing finally fails. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat, 16 Dec 2006, Dave Jones wrote: On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote: Anything else, you have to make some really scary decisions. Can a judge decide that a binary module is a derived work even though you didn't actually use any code? The real answer is: HELL YES. It's _entirely_ possible that a judge would find NVidia and ATI in violation of the GPLv2 with their modules. ATI in particular, I'm amazed their lawyers OK'd stuff like.. +ifdef STANDALONE MODULE_LICENSE(GPL); +endif This a paraphrased diff, it's been a while since I've seen it. It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko, but the usual use case is that it's built-in to fglrx.ko, which sounds incredibly dubious. Now, AGPGART has a murky past wrt licenses. It initally was imported into the tree with the license GPL plus additional rights. Nowhere was it actually documented what those rights were, but I'm fairly certain it wasn't to enable nonsense like the above. As it came from the XFree86 folks, it's more likely they really meant Dual GPL/MIT or similar. When I took over, any new code I wrote I explicitly set out to mark as GPL code, as my modifications weren't being contributed back to X, they were going back to the Linux kernel. ATI took those AGPv3 modifications from a 2.5 kernel, backported them to their 2.4 driver, and when time came to do a 2.6 driver, instead of doing the sensible thing and dropping them in favour of using the kernel AGP driver, they chose to forward port their unholy abomination to 2.6. It misses so many fixes (and introduces a number of other problems) that its just unfunny. The thing that really ticks me off though is the free support ATI seem to think they're entitled to. I've had end-users emailing me I asked ATI about this crash I've been seeing with fglrx, and they asked me to mail you. I invest my time into improving free drivers. When companies start expecting me to debug their part binary garbage mixed with license violations, frankly, I think they're taking the piss. A year and a half ago, I met an ATI engineer at OLS, who told me they were going to 'resolve this'. I'm still waiting. I live in hope that the AMD buyout will breathe some sanity into ATI. Then again, I've only a limited supply of optimism. You would think ATI's steaming pile of crap would be a good reason for them to give up on the whole binary module thing and just release specs so someone else can write a decent driver. I made the mistake of purchasing an ATI X1600. No open kernel driver.. no open X driver. The ATI drivers don't even complile on amd64 on any recent kernel and their X drivers are prone to random screen corruption that requires nothing less than a full reboot to clear. IMO let those morons keep writing themselves into a corner with this crud and then perhapse they will see for themselves that binary modules are a horribly bad idea instead of having someone else to blame when this whole thing finally fails. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.11.6: Mach64 driver spams the console
Can someone please explain why I get this every time I switch in and out of X? And better yet how do I turn this off? debug atyfb: Mach64 non-shadow register values: debug atyfb: 0x2000: 004F0063 000C0052 01DF020C 000201EA debug atyfb: 0x2010: 016F 1400 0020 0B002200 debug atyfb: 0x2020: 005B04BC 0068048E 00382848 debug atyfb: 0x2030: 00200213 C001 debug atyfb: 0x2040: 0450098B debug atyfb: 0x2050: 04C506DB debug atyfb: 0x2060: AA0F 0007FE00 00300088 debug atyfb: 0x2070: 0030 3700 48833800 debug atyfb: 0x2080: 04900400 0F0B000C 00020002 debug atyfb: 0x2090: 00803003 0A000100 debug atyfb: 0x20A0: 7B23A050 0107 6001 E5000CF1 debug atyfb: 0x20B0: 00165A27 0001 0001 debug atyfb: 0x20C0: 00FF0010 86010182 debug atyfb: 0x20D0: 0100 007F0179 3F02 debug atyfb: 0x20E0: 65004752 00410096 debug atyfb: 0x20F0: F6FE FB8004F8 debug atyfb: Mach64 PLL register values: debug atyfb: 0x00: ADD51FE4 8103FFDA F500DA0A 801B debug atyfb: 0x10: 00CF4000 10ADAC10 400024FD 0002 debug atyfb: 0x20: 06AC0610 1424FD00 00195500 debug atyfb: 0x30: -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11.6: Mach64 driver spams the console
Can someone please explain why I get this every time I switch in and out of X? And better yet how do I turn this off? debug atyfb: Mach64 non-shadow register values: debug atyfb: 0x2000: 004F0063 000C0052 01DF020C 000201EA debug atyfb: 0x2010: 016F 1400 0020 0B002200 debug atyfb: 0x2020: 005B04BC 0068048E 00382848 debug atyfb: 0x2030: 00200213 C001 debug atyfb: 0x2040: 0450098B debug atyfb: 0x2050: 04C506DB debug atyfb: 0x2060: AA0F 0007FE00 00300088 debug atyfb: 0x2070: 0030 3700 48833800 debug atyfb: 0x2080: 04900400 0F0B000C 00020002 debug atyfb: 0x2090: 00803003 0A000100 debug atyfb: 0x20A0: 7B23A050 0107 6001 E5000CF1 debug atyfb: 0x20B0: 00165A27 0001 0001 debug atyfb: 0x20C0: 00FF0010 86010182 debug atyfb: 0x20D0: 0100 007F0179 3F02 debug atyfb: 0x20E0: 65004752 00410096 debug atyfb: 0x20F0: F6FE FB8004F8 debug atyfb: Mach64 PLL register values: debug atyfb: 0x00: ADD51FE4 8103FFDA F500DA0A 801B debug atyfb: 0x10: 00CF4000 10ADAC10 400024FD 0002 debug atyfb: 0x20: 06AC0610 1424FD00 00195500 debug atyfb: 0x30: -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001, Jeff Garzik wrote: > Linus Torvalds wrote: > > Things like version strings etc sound useful, but the fact is that the > > only _real_ problem it has ever solved for anybody is when somebody thinks > > they install a new kernel, and forgets to run "lilo" or something. But > > even that information you really get from a simple "uname -a". > > > > Do we care that when you boot kernel-2.4.5 you get "net-3"? No. Do we care > > that we have quota version "dquot_6.4.0"? No. Do we want to get the > > version printed for every single driver we load? No. > > > > If people care about version printing, it (a) only makes sense for modules > > and (b) should therefore maybe be done by the module loader. And modules > > already have the MODULE_DESCRIPTION() thing, so they should NOT printk it > > on their own. modprobe can do it if it wants to. > > As Alan said, driver versions are incredibly useful. People use update > their drivers over top of kernel drivers all the time. Vendors do it > too. "Run dmesg and e-mail me the output" is 1000 times more simple for > end users. Why not a generic way to query the drivers for version info from userspace? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, 28 Jun 2001, Jeff Garzik wrote: Linus Torvalds wrote: Things like version strings etc sound useful, but the fact is that the only _real_ problem it has ever solved for anybody is when somebody thinks they install a new kernel, and forgets to run lilo or something. But even that information you really get from a simple uname -a. Do we care that when you boot kernel-2.4.5 you get net-3? No. Do we care that we have quota version dquot_6.4.0? No. Do we want to get the version printed for every single driver we load? No. If people care about version printing, it (a) only makes sense for modules and (b) should therefore maybe be done by the module loader. And modules already have the MODULE_DESCRIPTION() thing, so they should NOT printk it on their own. modprobe can do it if it wants to. As Alan said, driver versions are incredibly useful. People use update their drivers over top of kernel drivers all the time. Vendors do it too. Run dmesg and e-mail me the output is 1000 times more simple for end users. Why not a generic way to query the drivers for version info from userspace? Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> BTW, after all I have read all POSIX threads library should be no more than > a wrapper over fork(), clone and so on. Why are they so bad then ? > I am going to get glibc source to see what is inside pthread_create... If I recall it had to do with problems in signal delivery... -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
BTW, after all I have read all POSIX threads library should be no more than a wrapper over fork(), clone and so on. Why are they so bad then ? I am going to get glibc source to see what is inside pthread_create... If I recall it had to do with problems in signal delivery... -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT]Re: One more ZDNet article with BillG hammering Linux and OpenSource.
On Fri, 22 Jun 2001, Ben Ford wrote: > Miles Lane wrote: > > >http://www.zdnet.com/zdnn/stories/news/0,4586,2777283,00.html > > > [ . . . ] > > > > >BillG -- We keep making it easier and easier, and anything people want source > >code for, we'll figure out a way to get it to them. It's kind of a strange > >thing in a way because most commercial customers don't want to recompile > >kernels or things like that. But they want to be able to know that things can > >be supported. > > > >We have some very cool tools now where we don't have to ship you the source. > >You can debug online, through the Internet. So it means you don't have to get > >a bunch of CDs. If you really want it for debugging and patching things, we > >can do that through the Internet. That's a real breakthrough in terms of > >simple source access. I don't know that anyone has ever asked for the source > >code for Word. If they did, we would give it to them. But it's not a typical > >request. > >- > > > > Hey, Bill, here's my address, can you ship me the full source to Word? Funny but by giving it to you they could really screw you when it comes to opensource work. If you think the GPL is viral you havn't seen "shared source".. at least the GPL only applies to derived works. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT]Re: One more ZDNet article with BillG hammering Linux and OpenSource.
On Fri, 22 Jun 2001, Ben Ford wrote: Miles Lane wrote: http://www.zdnet.com/zdnn/stories/news/0,4586,2777283,00.html [ . . . ] BillG -- We keep making it easier and easier, and anything people want source code for, we'll figure out a way to get it to them. It's kind of a strange thing in a way because most commercial customers don't want to recompile kernels or things like that. But they want to be able to know that things can be supported. We have some very cool tools now where we don't have to ship you the source. You can debug online, through the Internet. So it means you don't have to get a bunch of CDs. If you really want it for debugging and patching things, we can do that through the Internet. That's a real breakthrough in terms of simple source access. I don't know that anyone has ever asked for the source code for Word. If they did, we would give it to them. But it's not a typical request. - Hey, Bill, here's my address, can you ship me the full source to Word? Funny but by giving it to you they could really screw you when it comes to opensource work. If you think the GPL is viral you havn't seen shared source.. at least the GPL only applies to derived works. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Re: Linux 2.4.5-ac6
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote: > On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: > > On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: > > > > Exactly. However, there are situations when you have only two options: > > > rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) > > > > Why can't mozilla be fixed? With the -taso option there is actually less > > encouragement to do so. > > Mozilla is fine. Its netscape 4.X that probably needs -taso. And only the old netscape 4.x releases at that afik the newer releases are all compiled ELF. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Re: Linux 2.4.5-ac6
On Fri, 8 Jun 2001 [EMAIL PROTECTED] wrote: On Thu, Jun 07, 2001 at 08:31:46PM +0200, Maciej W. Rozycki wrote: On Thu, 7 Jun 2001, Ivan Kokshaysky wrote: Exactly. However, there are situations when you have only two options: rewrite from scratch or use -taso. Netscape vs. mozilla is a good example. :-) Why can't mozilla be fixed? With the -taso option there is actually less encouragement to do so. Mozilla is fine. Its netscape 4.X that probably needs -taso. And only the old netscape 4.x releases at that afik the newer releases are all compiled ELF. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Accelerated TCP/IP support from kernel
I'm curious.. do your cards support IPv6 and ECN ? Gerhard On Thu, 24 May 2001, Bharath Madhavan wrote: > Thanks a lot. That was useful info especially your last point > where you are saying that most of the area we can save is in > data processing and not in protocol processing. > So, if we use the ZERO_COPY feature, we should gain quite a bit. > I guess 3c905c NIC supports HW checksumming. Is this true? > In this case, do we have any benchmarking for this card > with and without ZERO_COPY (and HW checksumming). I am eager to > know by how many times did the system throughput increase? > Thanks a lot > Bharath > > > > > -Original Message- > From: David S. Miller [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 24, 2001 6:29 PM > To: Bharath Madhavan > Cc: [EMAIL PROTECTED] > Subject: Re: Accelerated TCP/IP support from kernel > > > > Bharath Madhavan writes: > >I am looking into a scenario where we have a NIC which performs > > all the TCP/IP processing and basically the core CPU offloads all data > from > > the socket level interface onwards to this NIC. > > Why would you ever want to do this? > > Point 1: Support for new TCP techniques and bug fixes are hard enough > to propagate to user's systems as it is with the implementation being > done in software. > > Point 2: If I find a bug in the cards TCP implementation, will I be > able to get at the source for the firmware and fix it? Likely the > answer to this is no. > > Every couple years a few vendors make cards like this, yet ignore > these core issues. It is currently impractical to use these kinds of > cards today except in a few very special case situations. > > Furthermore, the actual protocol processing overhead is quite small > and almost neglible especially on today's gigahertz beasts. The data > copy is where the time is spent, and checksum offload takes care of > that. > > Later, > David S. Miller > [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/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Accelerated TCP/IP support from kernel
I'm curious.. do your cards support IPv6 and ECN ? Gerhard On Thu, 24 May 2001, Bharath Madhavan wrote: Thanks a lot. That was useful info especially your last point where you are saying that most of the area we can save is in data processing and not in protocol processing. So, if we use the ZERO_COPY feature, we should gain quite a bit. I guess 3c905c NIC supports HW checksumming. Is this true? In this case, do we have any benchmarking for this card with and without ZERO_COPY (and HW checksumming). I am eager to know by how many times did the system throughput increase? Thanks a lot Bharath -Original Message- From: David S. Miller [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 24, 2001 6:29 PM To: Bharath Madhavan Cc: [EMAIL PROTECTED] Subject: Re: Accelerated TCP/IP support from kernel Bharath Madhavan writes: I am looking into a scenario where we have a NIC which performs all the TCP/IP processing and basically the core CPU offloads all data from the socket level interface onwards to this NIC. Why would you ever want to do this? Point 1: Support for new TCP techniques and bug fixes are hard enough to propagate to user's systems as it is with the implementation being done in software. Point 2: If I find a bug in the cards TCP implementation, will I be able to get at the source for the firmware and fix it? Likely the answer to this is no. Every couple years a few vendors make cards like this, yet ignore these core issues. It is currently impractical to use these kinds of cards today except in a few very special case situations. Furthermore, the actual protocol processing overhead is quite small and almost neglible especially on today's gigahertz beasts. The data copy is where the time is spent, and checksum offload takes care of that. Later, David S. Miller [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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
> Its what I would describe as lack of enforcement by trading standards bodies, > and I suspect what the US would call 'insufficient class action lawsuits' What we need is a web page for listing crap hardware so less people buy it. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mount /dev/hdb2 /usr; swapon /dev/hdb2 keeps flooding
On Sat, 12 May 2001, Alexander Viro wrote: > > > On Sun, 13 May 2001, BERECZ Szabolcs wrote: > > > On Sat, 12 May 2001, Alexander Viro wrote: > > > > > - Doctor, it hurts when I do it! > > > - Don't do it, then. > > > > > > Just what behaviour had you expected? > > maybe that I don't have to shutdown? > > I think it's a *bad* behaviour > > Erm... Let me restate: what did you expect to achieve with that? > Swap on device means that all contents of that device is lost. > Mounting fs from device generally means that you don't want the > loss of contents. At least until you unmount the thing. > Really? Then why do 2.4.x kernels let you mkfs a mounted fs? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mount /dev/hdb2 /usr; swapon /dev/hdb2 keeps flooding
On Sat, 12 May 2001, Alexander Viro wrote: On Sun, 13 May 2001, BERECZ Szabolcs wrote: On Sat, 12 May 2001, Alexander Viro wrote: - Doctor, it hurts when I do it! - Don't do it, then. Just what behaviour had you expected? maybe that I don't have to shutdown? I think it's a *bad* behaviour Erm... Let me restate: what did you expect to achieve with that? Swap on device means that all contents of that device is lost. Mounting fs from device generally means that you don't want the loss of contents. At least until you unmount the thing. Really? Then why do 2.4.x kernels let you mkfs a mounted fs? Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Status of VIA chipsets and 2.2 kernels
Ugh why VIA? They have been a constant source of trouble for me on both linux and windows. I have my doubts about their ability to get a chipset right in the first place. Some other possible Athlon boards: Asus A7M266 (AMD chipset) Asus A7A266 (ALI chipset) On Wed, 9 May 2001, Robert Cohen wrote: > What with all the various problem reports flying around for via > chipsets, Ive lost track of the state of play as regards via > northbridges and south bridges. > I am thinking of buying a machine with a via chipset and I wan't to know > how stable it is likely to be with Linux. > I would appreciate it if someone who know's whats going on can give a > report on the state of play > as regards to all the problems and their current status with 2.2 kernels > (and 2.4 if their feeling energetic). > > Possible machine are: > a P3 machine with a ASUS CUV4X-E motherboard which uses the apollo pro > 694X northbridge and a 686B southbridge. > > An athlon machine with an ASUS A7V motherboard which uses a KT133 > (VT8363) northbridge and a 686A southbridge. > > An athlon machine with an ASUS A7V133 motherboard which uses a KT133A > (VT8363A) northbridge and a 686B southbridge. > > Problems Ive been hearing about include DMA disk transfers between > channels. Some reports say these only occur with Western digital disks. > The 2 athlon boards listed include an onboard promise IDE controller. So > I should be OK if I use this for disks, right? > > Any other problems I should know about? > > > -- > Robert Cohen > Unix Support > TLTSU > Australian National University > Ph: 612 58389 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question: Status of VIA chipsets and 2.2 kernels
Ugh why VIA? They have been a constant source of trouble for me on both linux and windows. I have my doubts about their ability to get a chipset right in the first place. Some other possible Athlon boards: Asus A7M266 (AMD chipset) Asus A7A266 (ALI chipset) On Wed, 9 May 2001, Robert Cohen wrote: What with all the various problem reports flying around for via chipsets, Ive lost track of the state of play as regards via northbridges and south bridges. I am thinking of buying a machine with a via chipset and I wan't to know how stable it is likely to be with Linux. I would appreciate it if someone who know's whats going on can give a report on the state of play as regards to all the problems and their current status with 2.2 kernels (and 2.4 if their feeling energetic). Possible machine are: a P3 machine with a ASUS CUV4X-E motherboard which uses the apollo pro 694X northbridge and a 686B southbridge. An athlon machine with an ASUS A7V motherboard which uses a KT133 (VT8363) northbridge and a 686A southbridge. An athlon machine with an ASUS A7V133 motherboard which uses a KT133A (VT8363A) northbridge and a 686B southbridge. Problems Ive been hearing about include DMA disk transfers between channels. Some reports say these only occur with Western digital disks. The 2 athlon boards listed include an onboard promise IDE controller. So I should be OK if I use this for disks, right? Any other problems I should know about? -- Robert Cohen Unix Support TLTSU Australian National University Ph: 612 58389 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bandwidth
On Tue, 1 May 2001, mirabilos wrote: > Another point: look at the headers. I'd like LKML to > strip all these X- thingies, the "Received:" etc. > so that the messages I get have a bare minimum header > consisting just of To: and Subject: (maybe MIME). > Er you wish to remove the abillity to trace abusive email? -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bandwidth
On Tue, 1 May 2001, mirabilos wrote: Another point: look at the headers. I'd like LKML to strip all these X- thingies, the Received: etc. so that the messages I get have a bare minimum header consisting just of To: and Subject: (maybe MIME). Er you wish to remove the abillity to trace abusive email? -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
On Mon, 30 Apr 2001, Eric S. Raymond wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > I think ppl are recommending you BZ2 all your sigs.. > > Yes, I got that. Except for the people saying they like them as-is. > > In the absence of a clear consensus on the matter, I'm going to do > as I please. Especially since I have a strong suspicion that neither > camp would change their evaluation of my sigs if I did compress them. Put them all on one long line and you can piss off a third camp. Gerhard PS I have a long rant on the topics your sigs cover but I would hate to see the resulting flamewar. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka I stick my neck out a mile...
On Mon, 30 Apr 2001, Eric S. Raymond wrote: [EMAIL PROTECTED] [EMAIL PROTECTED]: I think ppl are recommending you BZ2 all your sigs.. Yes, I got that. Except for the people saying they like them as-is. In the absence of a clear consensus on the matter, I'm going to do as I please. Especially since I have a strong suspicion that neither camp would change their evaluation of my sigs if I did compress them. Put them all on one long line and you can piss off a third camp. Gerhard PS I have a long rant on the topics your sigs cover but I would hate to see the resulting flamewar. -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Single user linux
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote:
[snip]
> so i guess i deserve opinions instead of flames. the
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
>
Heres one.. most of the time I spend cleaning up windows machines is not
because of software problems. Usually it's the user acidentally erasing
something or installing some program that just modified the boot files by
accident.
Protection makes the system easier not harder. You can add SUID
aplications to preform administrative tasks such as upgrading / config and
be sure that the user won't accidentally erase the system.
I've had users absolutely paranoid of breaking something on my systems
it's very reasuring for me to be able to point at the power switch and say
"see that? don't touch it and the sustem will be fine"
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED]
<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Single user linux
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote: [snip] so i guess i deserve opinions instead of flames. the approach is from personal use, not the usual server use. if you think a server setup is best for all use just say so, i'm listening. Heres one.. most of the time I spend cleaning up windows machines is not because of software problems. Usually it's the user acidentally erasing something or installing some program that just modified the boot files by accident. Protection makes the system easier not harder. You can add SUID aplications to preform administrative tasks such as upgrading / config and be sure that the user won't accidentally erase the system. I've had users absolutely paranoid of breaking something on my systems it's very reasuring for me to be able to point at the power switch and say see that? don't touch it and the sustem will be fine Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Single user linux
On Wed, 25 Apr 2001, Daniel Stone wrote:
> OK. "time make bzImage". Of course, mine's really slow (and I will consider
> myself publically humiliated if my only Linux machine is beaten on a kernel
> compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to
> write "uptime" on it constitutes a walking penis extension after a while?
When I first started I compiled my linux kernels on a 386 dx with 8 mb ram
heh. I think a lot of the current PDAs are faster.
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED]
<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, 24 Apr 2001, Alan Cox wrote: > > On Tue, 24 Apr 2001, Mohammad A. Haque wrote: > > > Correct. <1024 requires root to bind to the port. > > ... And nothing says that it should be done by daemon itself. > > Or that you shouldnt let inetd do it for you > And that you shouldn't drop the capabilities except that bind > > It is possible to implement the entire mail system without anything running > as root but xinetd. > Qmail does exactly this afik. I've always found the root < 1024 to be quite limmited and find myself wishing I could assign permissions based on ip/port. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, 24 Apr 2001, Alan Cox wrote: On Tue, 24 Apr 2001, Mohammad A. Haque wrote: Correct. 1024 requires root to bind to the port. ... And nothing says that it should be done by daemon itself. Or that you shouldnt let inetd do it for you And that you shouldn't drop the capabilities except that bind It is possible to implement the entire mail system without anything running as root but xinetd. Qmail does exactly this afik. I've always found the root 1024 to be quite limmited and find myself wishing I could assign permissions based on ip/port. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Single user linux
On Wed, 25 Apr 2001, Daniel Stone wrote: OK. time make bzImage. Of course, mine's really slow (and I will consider myself publically humiliated if my only Linux machine is beaten on a kernel compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to write uptime on it constitutes a walking penis extension after a while? When I first started I compiled my linux kernels on a 386 dx with 8 mb ram heh. I think a lot of the current PDAs are faster. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: That leaked spam...
On Tue, 17 Apr 2001, Matti Aarnio wrote:
> Oops, something leaked thru, now I added couple filters which should
> bite on this, and one other mutation of the same kind...
> (Naturally I had to remove trap key-phrases from the text..)
>
> /Matti Aarnio
>
Is it possiblt to filter based on whether it has a domain name on the from
field ?
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED]
<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: That leaked spam...
On Tue, 17 Apr 2001, Matti Aarnio wrote: > Oops, something leaked thru, now I added couple filters which should > bite on this, and one other mutation of the same kind... > (Naturally I had to remove trap key-phrases from the text..) > > /Matti Aarnio > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: That leaked spam...
On Tue, 17 Apr 2001, Matti Aarnio wrote: Oops, something leaked thru, now I added couple filters which should bite on this, and one other mutation of the same kind... (Naturally I had to remove trap key-phrases from the text..) /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: That leaked spam...
On Tue, 17 Apr 2001, Matti Aarnio wrote: Oops, something leaked thru, now I added couple filters which should bite on this, and one other mutation of the same kind... (Naturally I had to remove trap key-phrases from the text..) /Matti Aarnio Is it possiblt to filter based on whether it has a domain name on the from field ? Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System clock loses time at approx 17 secs per two hours
Region 0: I/O ports at > > Region 1: I/O ports at > > Region 2: I/O ports at > > Region 3: I/O ports at > > Region 4: I/O ports at 4000 [size=16] > > > > 00:0b.0 Serial controller: Rockwell International HCF 56k V90 FaxModem (rev 01) >(prog-if 00 [8250]) > > Subsystem: Aztech System Ltd MDP3858SP-A SVD Modem > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- > > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- > Latency: 64 set > > Interrupt: pin A routed to IRQ 11 > > Region 0: Memory at e141 (32-bit, non-prefetchable) [size=64K] > > Capabilities: [40] Power Management version 1 > > Flags: PMEClk- AuxPwr+ DSI+ D1+ D2+ PME+ > > Status: D0 PME-Enable- DSel=0 DScale=3 PME- > > > > 00:14.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA >(rev 68) (prog-if 00 [VGA]) > > Subsystem: Silicon Integrated Systems [SiS]: Unknown device 0200 > > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- > > Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- > Interrupt: pin A routed to IRQ 0 > > Region 0: Memory at e100 (32-bit, prefetchable) [size=4M] > > Region 1: Memory at e140 (32-bit, non-prefetchable) [size=64K] > > Region 2: I/O ports at e000 [size=128] > > Expansion ROM at [disabled] [size=32K] > > > > -- > > /| _,.:*^*:., |\ Cheers from the Viking family, > > | |_/' viking@ `\_| |including Pippin, our cat > > |flying-brick| $FunnyMail Bilbo : Now far ahead the Road has gone, > > \_.caverock.net.nz_/ 5.39in LOTR : Let others follow it who can! > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: System clock loses time at approx 17 secs per two hours
Flags: PMEClk- AuxPwr+ DSI+ D1+ D2+ PME+ Status: D0 PME-Enable- DSel=0 DScale=3 PME- 00:14.0 VGA compatible controller: Silicon Integrated Systems [SiS] 5597/5598 VGA (rev 68) (prog-if 00 [VGA]) Subsystem: Silicon Integrated Systems [SiS]: Unknown device 0200 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 0 Region 0: Memory at e100 (32-bit, prefetchable) [size=4M] Region 1: Memory at e140 (32-bit, non-prefetchable) [size=64K] Region 2: I/O ports at e000 [size=128] Expansion ROM at unassigned [disabled] [size=32K] -- /| _,.:*^*:., |\ Cheers from the Viking family, | |_/' viking@ `\_| |including Pippin, our cat |flying-brick| $FunnyMail Bilbo : Now far ahead the Road has gone, \_.caverock.net.nz_/ 5.39in LOTR : Let others follow it who can! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel IRC Room?
On Wed, 28 Mar 2001, Alexander Valys wrote: > Is there a kernel development irc room anywhere? If not, does anyone think > it might be useful? #kernelnewbies on irc.openprojects.net. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disturbing news..
On Wed, 28 Mar 2001 [EMAIL PROTECTED] wrote:
> Jesse Pollard writes:
> > Absolutely true. The only help the checksumming etc stuff is good for is
> > detecting the fact afterward by external comparison.
>
> Don't we already have that to some extent? rpm -ya or rpm -y
> on a RedHat system? I'm sure that there is a Debian equivalent.
http://www.tripwire.com does exactly this afik.
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED]
<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Disturbing news..
On Wed, 28 Mar 2001 [EMAIL PROTECTED] wrote: Jesse Pollard writes: Absolutely true. The only help the checksumming etc stuff is good for is detecting the fact afterward by external comparison. Don't we already have that to some extent? rpm -ya or rpm -y package name on a RedHat system? I'm sure that there is a Debian equivalent. http://www.tripwire.com does exactly this afik. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel IRC Room?
On Wed, 28 Mar 2001, Alexander Valys wrote: Is there a kernel development irc room anywhere? If not, does anyone think it might be useful? #kernelnewbies on irc.openprojects.net. -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Fri, 23 Mar 2001, Bob Lorenzini wrote: > I'm annoyed when persons post virus alerts to unrelated lists but this > is a serious threat. If your offended flame away. This should be a wake up call... distributions need to stop using product with consistently bad security records. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux should better cope with power failure
This sounds very nice.. can such a thing be done with the reset switch as well? Gerhard On Fri, 23 Mar 2001, David Balazic wrote: > I had a similar experience: > X crashed , hosing the console , so I could not initiate > a proper shutdown. > > Here I must note that the response you got on linux-kernel is > shameful. > > What I did was to write a kernel/apmd patch , that performed a > proper shutdown when I press the power button ( which luckily > works as long as the kernel works ). > > Ask me for details, if interested. > The patch was for 2.2.x IIRC, so I would have to rewrite it almost > from scratch. > > > Otto Wyss ([EMAIL PROTECTED]) wrote : > > > Lately I had an USB failure, leaving me without any access to my system > > since I only use an USB-keyboard/-mouse. All I could do in that > > situation was switching power off and on after a few minutes of > > inactivity. From the impression I got during the following startup, I > > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > > failiure or manually switching it off. Not even if there wasn't any > > activity going on. > > > > Shouldn't a good system allways try to be on the save side? Shouldn't > > Linux try to be more fail save? There is currently much work done in > > getting high performance during high activity but it seems there is no > > work done at all in getting a save system during low/no activity. I > > think this is a major drawback and should be addressed as fast as > > possible. Bringing a system to save state should allway have a high priority. > > > > How could this be accomplished: > > 1. Flush any dirty cache pages as soon as possible. There may not be any > > dirty cache after a certain amount of idle time. > > 2. Keep open files in a state where it doesn't matter if they where > > improperly closed (if possible). > > 3. Swap may not contain anything which can't be discarded. Otherwise > > swap has to be treated as ordinary disk space. > > > > These actions are not filesystem dependant. It might be that certain > > filesystem cope better with power failiure than others but still it's > > much better not to have errors instead to fix them. > > > > Don't we tell children never go close to any abyss or doesn't have > > alpinist a saying "never go to the limits"? So why is this simple rule > > always broken with computers? > > > > O. Wyss > > -- > David Balazic > -- > "Be excellent to each other." - Bill & Ted > - - - - - - - - - - - - - - - - - - - - - - > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux should better cope with power failure
This sounds very nice.. can such a thing be done with the reset switch as well? Gerhard On Fri, 23 Mar 2001, David Balazic wrote: I had a similar experience: X crashed , hosing the console , so I could not initiate a proper shutdown. Here I must note that the response you got on linux-kernel is shameful. What I did was to write a kernel/apmd patch , that performed a proper shutdown when I press the power button ( which luckily works as long as the kernel works ). Ask me for details, if interested. The patch was for 2.2.x IIRC, so I would have to rewrite it almost from scratch. Otto Wyss ([EMAIL PROTECTED]) wrote : Lately I had an USB failure, leaving me without any access to my system since I only use an USB-keyboard/-mouse. All I could do in that situation was switching power off and on after a few minutes of inactivity. From the impression I got during the following startup, I assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power failiure or manually switching it off. Not even if there wasn't any activity going on. Shouldn't a good system allways try to be on the save side? Shouldn't Linux try to be more fail save? There is currently much work done in getting high performance during high activity but it seems there is no work done at all in getting a save system during low/no activity. I think this is a major drawback and should be addressed as fast as possible. Bringing a system to save state should allway have a high priority. How could this be accomplished: 1. Flush any dirty cache pages as soon as possible. There may not be any dirty cache after a certain amount of idle time. 2. Keep open files in a state where it doesn't matter if they where improperly closed (if possible). 3. Swap may not contain anything which can't be discarded. Otherwise swap has to be treated as ordinary disk space. These actions are not filesystem dependant. It might be that certain filesystem cope better with power failiure than others but still it's much better not to have errors instead to fix them. Don't we tell children never go close to any abyss or doesn't have alpinist a saying "never go to the limits"? So why is this simple rule always broken with computers? O. Wyss -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Fri, 23 Mar 2001, Bob Lorenzini wrote: I'm annoyed when persons post virus alerts to unrelated lists but this is a serious threat. If your offended flame away. This should be a wake up call... distributions need to stop using product with consistently bad security records. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux on the Unisys ES7000 and CMP2 machines?
On Sun, 4 Mar 2001, J Sloan wrote: > Miles Lane wrote: > > > http://www.nytimes.com/cnet/CNET_0-1003-200-5007472.html > > > > Hi, > > > > I noticed that this article mentions that Unisys has > > no plans to port Linux to it's "cellular multiprocessor" > > machines. So, I am wondering if anyone is working > > on this independantly. > > > > These systems seems to be selling well with Microsoft's > > Windoze 2000 Datacenter installed. > > My take on it is that unisys is an example of brain damage > and it's easiest to ignore/work around them rather than > trying to get them out of bed with microsoft. Nature will > eventually take it's course with unisys as it did with Dec. > Given Unisys' reputation you would think compaq and HP would leave them alone to avoid being dirtied. I think after the gif fiasco most people on the net hate that company. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
