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: [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: Is this the ultimate stack-smash fix?
> Is there any documentation of the kernel's 'capabilities' functions? It > would be exceedingly cool if services (named, nfs, etc) > could be updated to use this; I think crackers would loose some motivation > if instead of "hey I can totally rule this box!" > they have to settle for "hey I can make the ident service report user 'CrAp' > for every port!". Named and proftpd are already updated to use this.. check the source for the best documentation ... 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 stifles innovation... [way O.T.]
On Sat, 17 Feb 2001, Dennis wrote:
> BSDI is distributing FreeBSD now. They havent done anything useful to
> support it. They are just cashing in on it.
That's BS last I heard they were merging their SMP support.
Btw have you submitted bug reports for your networking card? If not you
have no one to blame but yourself for the fact that it's not working on
your system.
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/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > On Wed, 3 Jan 2001, Dan Hollis wrote: > > > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > > > Your comparing actual security with stack guarding? Stack guarding mearly > > > > makes the attack diffrent.. rootkits are already available to defeat it. > > > url? > > Ugh do you have any idea how hard it is to find 2 year old exploits? > > Heres the best I could find on short notice: > > http://www.insecure.org/sploits/non-executable.stack.problems.html > > http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html > > You said there were rootkits specifically targetting stackguard. > > These URLs simply describe attacks on stackguard, where are the > stackguard rootkits? I'll correct myself then: there were non exec stack patches. Keep in mind part of the problem is that some compilors actually use that feature look up "trampolines" for more info. Also I was in error to refer to it as stack guarding.. Stack guard is a compilor. I acually use libsafe it's preferable for 2 reasons. 1 It's entirely userspace and it works fine. 2 If someone manages to render it useless I'll simply uninstall it. Gerhard PS Although personally I think linux reoutation is most harmed by distribs who insists on installing software with bad security records. But that's not relevent to linux-kernel. -- 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] Please read the FAQ at http://www.tux.org/lkml/
RE: Change of policy for future 2.2 driver submissions
On Fri, 5 Jan 2001, Andre Tomt wrote: > I would wait for at least 2.4.10 on production systems (servers in > particular). Not to start a flame or anything (yeah, right), but 2.2.x was > not usable on such systems before it reached 2.2.16 IMHO. > > So, I guess, the "crippling" of driver submissions could hurt me bit, in > theory, which I don't like. ;-) I don't remember 2.2.0 being this well tested... I seem to recall it having a huge list of known bugs at the time too. 2.4.0 seems to have come with much better bug tracking and the time was spent fixing those bugs. Some of the servers I ran at the time wouldn't stabilize until 2.2.7 .. I'm betting on things going much more smoothly (though I won't know for sure since that company lost it's ability to afford me ;) ) 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] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel network problem ?
On Tue, 9 Jan 2001, Steven N. Hirsch wrote: > On Tue, 9 Jan 2001, Helge Hafting wrote: > > > Nicolas Noble wrote: > > [...] > > As others have told already, this is the ECN problem. > > > > > I noticed the same bug. This is very weired, I can send a list of sites > > > which I can't connect anymore. > > > > You have a list? Send all of them a message stating that they ought > > to upgrade their firewalls which cause this problem. Or they > > will loose customers/visitors. Cisco already have an upgrade for them, > > so fixing is dead easy, and they can then boast compatibility with > > the latest internet standards. > > > > If they don't care about linux users, tell them that windows eventually > > will use ECN too. They definitely don't want to have a ECN problem when > > that happens. > > After upgrading to kernel 2.4.0, I found myself unable to retrieve mail > from Adelphia's (2-way cable ISP) POP server. It took several days to > figure out that _one_ of their routers was configured to block ECN. After > bringing this to the attention of their network engineers, I was informed > that their policy prohibits making any router changes on the basis of one > trouble report. The person I spoke with did NOT try to defend their > setup, but it was made clear that they'll do nothing until Windows breaks. > > If I were packaging a Linux distribution, I'd be sure to have ECN disabled > by default, FWIW. > It's not a matter of changing network setup... if those are cisco routers there are patches to fix the bugs. Here is what little info I have on the topic (shamelessly ripped from an earlier email by "Dax Kelson <[EMAIL PROTECTED]>" ) Here is the fix for PIX: http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698 Bud ID:CSCds23698 Headline: PIX sends RSET in response to tcp connections with ECN bits set Product: PIX Component: fw Severity: 2Status: R [Resolved] Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207) 5.2(1.200) Here is the fix for Local Director: http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds40921 Bug Id : CSCds40921 Headline: LD rejects syn with reserved bits set in flags field of TCP hdr Product: ld Component: rotor Severity: 3 Status:R [Resolved] Version Found: 3.3(3) Fixed-in Version: 3.3.3.107 -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [Announcement] linux-kernel v2.0.39
GCC 2.95 will NOT compile a 2.0 series kernel... Gerhard > # gcc --version > 2.95.2 > > # uname -a > Linux eyal 2.4.0-ac3 #1 Sun Jan 7 12:15:50 EST 2001 i686 unknown > > # ls -l /lib/libc-*.so > -rwxr-xr-x1 root root 1057576 Oct 14 05:45 > /lib/libc-2.1.95.so > > -- > Eyal Lebedinsky ([EMAIL PROTECTED]) <http://samba.anu.edu.au/eyal/> > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
On Sun, 14 Jan 2001, Ingo Molnar wrote: > > On 14 Jan 2001, Linus Torvalds wrote: > > > Does anybody but apache actually use it? > > There is a Samba patch as well that makes it sendfile() based. Various > other projects use it too (phttpd for example), some FTP servers i > believe, and khttpd and TUX. Proftpd to name one ftp server, nice little daemon uses linux-privs too. Gerhard PS I wish someone would explain to me why distros insist on using WU instead given it's horrid security record. -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: The latest instance in the A20 farce
On Mon, 15 Jan 2001, H. Peter Anvin wrote: > "Albert D. Cahalan" wrote: > > > > It looks like we let Microsoft fill the design guide void. > > If you were to write "PC DESIGN GUIDE - For the Linux Operating > > System" and a pile of test code, then there would be an > > alternative to point people at. > > > > Complaining is pretty useless. > > I was thinking about this today. If we write a Linux design guide, even > as a delta spec, does anyone think it will be listed to? I imagine linux has enough market share to get at least some of them to listen to such a spec. For better results you might see if the *bsd people would want to collaberate on an open standard. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: multi-queue scheduler update
What affect does this scheduler have on 1 - 5 tasks?? Gerhard On Thu, 18 Jan 2001, Mike Kravetz wrote: > I just posted an updated version of the multi-queue scheduler > for the 2.4.0 kernel. This version also contains support for > realtime tasks. The patch can be found at: > > http://lse.sourceforge.net/scheduling/ > > Here are some very preliminary numbers from sched_test_yield > (which was previously posted to this (lse-tech) list by Bill > Hartner). Tests were run on a system with 8 700 MHz Pentium > III processors. > >microseconds/yield > # threads 2.2.16-22 2.42.4-multi-queue > - --- > 16 18.7404.603 1.455 > 32 17.7025.134 1.456 > 64 23.3005.586 1.466 > 128 47.273 18.812 1.480 > 256 105.701 71.147 1.517 > 512 FRC143.500 1.661 > 1024 FRC196.425 6.166 > 2048 FRC FRC 23.291 > 4096 FRC FRC 47.117 > > *FRC = failed to reach confidence level > > -- > Mike Kravetz [EMAIL PROTECTED] > IBM Linux Technology Center > 15450 SW Koll Parkway > Beaverton, OR 97006-6063 (503)578-3494 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Advanced Linux Kernel/Enterprise Linux Kernel
On Tue, 14 Nov 2000, Richard B. Johnson wrote: > On Tue, 14 Nov 2000, Michael Rothwell wrote: > > > "Richard B. Johnson" wrote: > > > > > Relating some "nine goals of 'Enterprise Computing'" to Multics is > > > the bullshit. > > > > Funny, I got those off the "Multics FAQ" page. > > > > -M > > > > > History is being rewritten. When Multics was being developed by AT&T, > it was found to be unusable on the DEC. It was a PDP-8, so the > story is told. General Electric got the first contract to make > a machine specifically designed for Multics and development > continued. > > The original DEC was "given" to W. M. Ritchie and his staff in > "Department 58213". He wanted to use it for games. To do so, required > him to write some sort of OS, which became Unix. > > As I said, when Multics was designed, the only criteria as to > get it to work on a DEC. It didn't. To use this development as > an example of "enterprise computing" is absurd and belies its > well documented history. But .. but... but they said so on slashdot. That must make it true. ;) -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: "No IRQ known for interrupt pin A..." error message
0 00 00 00 00 00 00 00 00 > > 00:07.0 Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- >SERR+ FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-Latency: 0 > 00: 86 80 10 71 0f 01 80 02 01 00 80 06 00 00 80 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 >[Master]) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-Latency: 32 > Region 4: I/O ports at 0860 [size=16] > 00: 86 80 11 71 05 00 80 02 01 80 01 01 00 20 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 61 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 >[UHCI]) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-Latency: 32 > Interrupt: pin D routed to IRQ 11 > Region 4: I/O ports at ece0 [size=32] > 00: 86 80 12 71 05 00 80 02 01 00 03 0c 00 20 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: e1 ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 04 00 00 > > 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01) > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 00: 86 80 13 71 03 00 80 02 01 00 80 06 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 05:00.0 Ethernet controller: 3Com Corporation 3c575 [Megahertz] 10/100 LAN CardBus >(rev 01) > Subsystem: 3Com Corporation 3C575 Megahertz 10/100 LAN Cardbus PC Card > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-Latency: 64 > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at 1800 [size=128] > Region 1: Memory at 1100 (32-bit, non-prefetchable) [size=128] > Region 2: Memory at 1180 (32-bit, non-prefetchable) [size=128] > Expansion ROM at 10c0 [size=128K] > Capabilities: [50] Power Management version 1 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA >PME(D0-,D1-,D2-,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: b7 10 57 51 07 00 10 02 01 00 00 02 00 40 00 00 > 10: 01 18 00 00 00 00 00 11 80 00 00 11 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 90 00 00 00 b7 10 57 5b > 30: 01 00 c0 10 50 00 00 00 00 00 00 00 0b 01 00 00 > > if i bring up the eth0 interface by hand the card works fine and i can > connect to the network. > > --alex-- > > -- > | I believe the moment is at hand when, by a paranoiac and active | > | advance of the mind, it will be possible (simultaneously with | > | automatism and other passive states) to systematize confusion | > | and thus to help to discredit completely the world of reality. | > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Universal debug macros.
On Mon, 27 Nov 2000, H. Peter Anvin wrote: > Chmouel Boudjnah wrote: > > > > "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > > > > > > > Something RedHat & co may want to consider doing is providing a basic > > > > > kernel and have, as part of the install procedure or later, an > > > > > automatic recompile and install kernel procedure. It could be > > > > > automated very easily, and on all but the very slowest of machines, it > > > > > really doesn't take that long. > > > > > > > > this completely not possible to do in regard of the end-users eyes. > > > > > > > > > > Why not? > > > > slow !! end-user want to install a distribution fast !!! > > > > it need a lot to be friendly the compilation (ie: we cannot do only > > launch of make xconfig, not everyone now which options to select), > > what we can do is a detection of the module and recompile a kernel > > with the detected module for recompilation but there is too much error > > case that could not be handle. > > > > It's not that slow compared to a whole distro install, although you would > of course want to do it *optionally*. You wouldn't want to get into > every single option, of course, but I thought that was obvious > (apparently not.) The drivers and stuff is the least of the problem -- > there, you can use modules anyway. > > -hpa > End users have bee known to try a kernel compile.. -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Chat Servers
And the problem with irc.openprojects.net is ... ? Gerhard On Sat, 2 Sep 2000, Michael Peddemors wrote: > Sorta off the topic, but just setup a 'Chat Room' For Linux Specific Topics... > If it is useful, we will expand the concept and set it up on a dedicated > server etc.. > http://www.linuxmagic.com/chat > > CHAT For Linux Only > > > Thought it would be nice for some people to hash out some of these ideas in > real time.. > > We havent' load tested this particular setup, but if all of a sudden > thousands of people start using it, well I guess that means the service is > needed, and we will do what it takes to satisfy everyone.. > > Only the Java Enabled browsers can take advantage of it so far, but again, if > the service gets used, I definitley will add telnet support.. .. > > Feel free to use it as much as you want.. It will stay live.. No matter if > only 2 people find it useful, or thousands.. > > Would be nice if we could get weekly chats together on say kernel development? > > Hope I haven't wasted our time with this, but it seemed that judging by some > of the threads, a quick chat could have sorted things out a lot quicker... > > BTW, our HTML guys haven't been able to keep up with everything and we > hurried a little to get this out there.. so I apologize in advance if anyone > notices some flaws or errors. > > If any problems using the chat PLEASE LET US KNOW right away. > > Thanks > > Again, URL is http://linuxmagic.com/chat > > Michael Peddemors - Senior Consultant > Unix Administration - WebSite Hosting > Network Services - Programming > Wizard Internet Services http://www.wizard.ca > Linux Support Specialist - http://www.linuxmagic.com > > (604) 589-0037 Beautiful British Columbia, Canada > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Test 8 Kernel Unable to get the password prompt?
That's not correct .. the latest until-linux does not appear to fix the
problem and there seems to be the same problem with PAM.
Gerhard
On Tue, 12 Sep 2000, Steven Walter wrote:
>
> If you're logging in as root, this is probably a result of the VT not
> being named in /etc/securetty. Devfsd mucks up the names, so you can
> either include "1," which would allow root logins from pseudo-terminals
> and other insecure places, or upgrade your util-linux to a newer
> version; I'm not sure what is new enough.
>
> On Mon, Sep 11, 2000 at 09:32:37PM -0700, Miles Lane wrote:
> >
> >
> > On Mon, 11 Sep 2000, David Freedom wrote:
> >
> > > I tried configuring the kernel to the least amount of
> > > configured options to almost none and I still cannot
> > > get the password prompt.
> > >
> > > My system hangs and is unable to do anything.
> > > unfortunetly the only thing I can do is power down my
> > > PC the incorrect and most unfortunate way leading to
> > > filesys errors upon reboot to an older saved kernel
> > > image.
> >
> > Are you getting both the username and password prompts
> > and then getting nothing after entering the password?
> > This is a behavior I am seeing on a laptop Pentium II.
> > In my case, I can CTRL-ALT-F[1-6] to get to another
> > VT. All attempts to log in any VT display meet the same
> > fate. Also, attempting to log in using GDM fail in
> > this way. In my case, the UI GDM continues to respond.
> >
> > Lastly, trying to CTRL-ALT-DEL to initiate a shutdown
> > does cause the TERM and KILL signals to be sent to
> > all processes. Then the shutdown process locks up
> > after a message is printed about unloading the
> > keyboard driver.
> >
> > Interestingly, if I boot in single mode ("linux single"
> > at the boot prompt), and then load GDM, I am able to
> > log on with no trouble.
> >
> > I have sent a message to the maintainer of the
> > shadow-utils package, but have gotten no response.
> >
> > I suspect this problem has to do with a fsck-up on
> > my part in getting util-linux configured properly when
> > I built it. I rebuilt util-linux with the sources
> > pointed to by Changes several development kernel
> > revisions ago (~2.4.0-test7).
> >
> > Miles
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > 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]
> 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]
Please read the FAQ at http://www.tux.org/lkml/
test9-pre2 fails to compile with ipv6 enabled
Got this from a fresh tree:
net/network.o: In function `inet6_proto_init':
net/network.o(.text.init+0x191d): undefined reference to `igmp6_cleanup'
make: *** [vmlinux] Error 1
--
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]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre3: sit tunnel problems
ifconfig sit0 up tunnel ::206.123.31.102 SIOCSIFDSTADDR: No buffer space available Anyone know why it does this? I can't seem to find any documentation on that error... 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] Please read the FAQ at http://www.tux.org/lkml/
RE [OT] Reply to headder..
> Reply ALL also results in 2 mails being sent instead of one but of > course this is usually not a problem since one is going direct and the > other is going through vger, but still... it's kind of wasteful to > resources and i dont see any harm in Reply-to being sent in the > header. > Proftpd's mailing list seems to work fine with it. Is your position > against it just due to client incompatibility? Yes, it increases list traffic with things that don't need to be on the list. The odd second email isn't nearly as bad as seeing 100 posts that don't need to be on the lists accidentally sent here. In practice the majority of my linux-kernel email replies tend to not be back to the list. Which is more wasteful of resources: 100 second emails? or 10 extras sent to a few thousand subscribers? The majority of my linux-kernel email replies tend to not be back to the list. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic (or maybe on-topic)
On Fri, 27 Oct 2000 [EMAIL PROTECTED] wrote:
> If Bill said 'screw you' to the blackmailer and made the press release,
> we should see the source on web sites soon. Then we can see how bad it
> really is. Maybe even fix it.
>
Or better yet: use it to write an interface spec so we can get wine to run
anything windows does.
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]
Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, James A. Sutherland wrote: > Except this isn't possible with the hardware in question! If it were, there > would be no problem. In cases where the hardware doesn't support the > functionality userspace "needs", why put the kludge in the kernel? > > If userspace wants to know what settings it set last time, it should store > those values somewhere. > > > [EMAIL PROTECTED] said: > > > The right thing in this context is not to screw with hardware > > > settings unless and until it is given settings to set. Do not set > > > values arbitrarily: set only the values you are explicitly given. > > > Anything else is simply a bug in your driver. > > > > It is unwise to assume that the hardware is in a sane state when the driver > > has been unloaded and reloaded. I agree that you should set the values that > > were explicitly given. That's why we should remember them. > > No values are being explicitly given. Loading the driver should not cause > any settings to be changed: changing the settings should do that! > > There is no need for the drivers to change any settings. If the settings need > to be (re)set, let userspace do it. > > > James. Sure .. lets see you start a laptop in class or buisness meeting and have everyone turn to look at you wondering why your laptop let off an ear piercing shreak because the hardware defaults to all settings max. And you will _STILL_ have that shriek for 1/2 - 1 second before the userspace app loads. And no we couldn't unplug either the mike or the speakers since they come embedded in the laptop's case. I don't see in any of your trolling an answer for this problem. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 7 Nov 2000, James A. Sutherland wrote: > On Mon, 06 Nov 2000, Gerhard Mack wrote: > > Sure .. lets see you start a laptop in class or buisness meeting and have > > everyone turn to look at you wondering why your laptop let off an ear > > piercing shreak because the hardware defaults to all settings max. > > That only happens if the driver is stupid enough to try guessing "correct" > volume settings. If it leaves well alone until it KNOWS the correct settings, > there is no ear piercing shriek. Nor is there any break in the sound if you > were listening to something from the mixer. > > > And you will _STILL_ have that shriek for 1/2 - 1 second before the > > userspace app loads. > > Wrong. The userspace app is the one triggering the device init, when it gives > the sound driver the correct volume settings. There is no half second delay. > > > And no we couldn't unplug either the mike or the speakers since they come > > embedded in the laptop's case. > > > > I don't see in any of your trolling an answer for this problem. > > It isn't trolling, and there is a perfectly simple answer, as I have already > explained. > And if I don't use modules? 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
> Then none of this is relevant to you, since you can't unload any modules! And > now you're the one doing the trolling... WTF do you think module code is > supposed to do when you don't use modules?! > Simple ... I'd rather the hardware was set to 0 on startup but I know what problems that presents to modules.. And no it wasn't the driver doing it afik. Sound card starts on max volume as soon as it's initialised. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
On Mon, 11 Dec 2000, Alan Cox wrote: > > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test > > for the VM doesn't make any sense since it doesn't really excercise > > the VM in any way... > > Its an interesting demo that 2.4 has some performance problems since 2.2 > is slower than 2.0 although nowdays not much. How much of that is due to the fact that the 2.4.0 scheduler interrupts processes more often than 2.2.x? Is the better interactivity worth the slight drop in performance? 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] Please read the FAQ at http://www.tux.org/lkml/
Re: OS & Games Software
On Sat, 23 Dec 2000, Alex Belits wrote: > On Sat, 23 Dec 2000 [EMAIL PROTECTED] wrote: > > > Subject: OS & Games Software > > > > Are you still using an old operating system? Why not upgrade to a > > newer and > > more reliable version? You'll enjoy greater features and more > > stability. > > > > Microsoft Dos 6.22 $15 > > Microsoft Windows 3.11 $15 > > Microsoft Windows 95$15 > > Microsoft Windows 98 SE $20 > > Microsoft Windows Millenium $20 > > Microsoft Windows 2000 Pro $20 > > Microsoft Windows 2000 Server $50 > > Microsoft Windows 2000 Advanced Server (25CAL) $65 > > > > Is this a desperate Microsoft's attempt to slow Linux development by > insulting developers? ;-)) > > I mean, what other purpose can this possibly have? Unless, of course, > some unintelligent person got linux-kernel address in a list of > prepackaged "n millions email addresses for sale" (and then he must be not > moron*2, or moron^2, but at least e^moron). I vote moron ... hes within a day's drive of MS though. ISP can be contacted at: 1-800-356-LOOK (5665) Considering it's been the same dork with no response to complaint emails the isp is looking spam friendly. Lets cost them a bit and see if they hurry up and terminate this loser. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Thu, 4 Jan 2001, Dan Aloni wrote: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > > > without breaking anything. It also reports of such calls by using printk. > > > > Get real. > > > > > > Why do you always have to be insulting alex? Sheesh. > > > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is > [..] > > Did you notice that question was ambiguous? I understood that sentence in > its other meaning, i.e, someone insulting Alex ;-) > > Anyway, while it is agreed that you can't completely eliminate exploits, > it is recommended that, it should be at least harder to create them, maybe > it can even minimize the will to write them. > > -- > Dan Aloni > [EMAIL PROTECTED] > You are much better off working on ways to reduce the number of processes that need to be root.. As for these protections my system emails me when a process overflows it's buffers, But that's not a kernel function. ;) 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Thu, 4 Jan 2001, Dan Aloni wrote: > > Anyway, while it is agreed that you can't completely eliminate exploits, > > it is recommended that, it should be at least harder to create them, maybe > > it can even minimize the will to write them. > > The argument against these sort of protection mechanisms seems to be "well > its not perfect, so we shouldnt have it at all". > > Lets use that argument against uid/gid then. Since it's impossible to > protect against exploits, let's dispose of uid/gid entirely and run > everything as root ;-) > > "stack guarding is a false sense of security". Well, so is ipchains, so > lets discard that as well...? > > Really, these arguments cut both ways. If you are going to argue against > something because it's not perfect, you should be aware that you're > arguing against other kernel protection mechanisms also. > Your comparing actual security with stack guarding? Stack guarding mearly makes the attack diffrent.. rootkits are already available to defeat 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > Your comparing actual security with stack guarding? Stack guarding mearly > > makes the attack diffrent.. rootkits are already available to defeat it. > > url? Ugh do you have any idea how hard it is to find 2 year old exploits? Heres the best I could find on short notice: http://www.insecure.org/sploits/non-executable.stack.problems.html http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html -- 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] Please read the FAQ at http://www.tux.org/lkml/
ip6 in up4 tunnel still broken in test9-pre7
[root@innerfire /root]# ifconfig sit0 tunnel ::206.123.31.102 SIOCSIFDSTADDR: No buffer space available This is with net-tools 1.57 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] Please read the FAQ at http://www.tux.org/lkml/
Re: Majordomo is sick
It's not majodomo. It's somone who is subscribed to the list bouncing things back. Could be a broken mail to news gateway or some other mis scripted feature. Read the mail headers and you can see fairly quickly who is responsable. Gerhard On Thu, 5 Oct 2000, Jeff V. Merkey wrote: > > > [EMAIL PROTECTED] is sick and is sending messages in a circle. > Better check the /etc/aliases file and make sure a record isn't pointing > somewhere it should not. > > Jeff > > [Fwd: Returned mail: Too many hops 29 (25 max): from > <[EMAIL PROTECTED]> via vger.kernel.org, to > <[EMAIL PROTECTED]>] -- 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] Please read the FAQ at http://www.tux.org/lkml/
will ip 6 in ip4 tunnelling be fixed anytime soon ?
Is there an ETA on having ip6 in ip4 tunnelling working with the latest net-utils?? -- 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] Please read the FAQ at http://www.tux.org/lkml/
Re: will ip 6 in ip4 tunnelling be fixed anytime soon ?
On Sun, 8 Oct 2000, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Is there an ETA on having ip6 in ip4 tunnelling working with the latest > > net-utils?? > > what is the problem? Do u have a bug or do u mean general IPv6 Support? > There are a lot of unoficial IPv6 Packages, Debian has a good Collection, > and we are trying to get them back into the Upstream. > > For net-tools, everything should be ok with 1.57 > > Greetings > Bernd I would call this a bug: [root@innerfire /root]# ifconfig sit0 tunnel ::206.123.31.102 SIOCSIFDSTADDR: No buffer space available [root@innerfire /root]# ifconfig -V net-tools 1.57 ifconfig 1.40 (2000-05-21) Dmesg confirms I've compiled in support: IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver early initialization of device sit0 is deferred 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] 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: 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: 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: System clock loses time at approx 17 secs per two hours
ted to IRQ 14 > > 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: DNS goofups galore...
Thanklfully bind 9 barfs if you even try this sort of thing. Gerhard On Thu, 8 Feb 2001, Henning P. Schmiedehausen wrote: > [EMAIL PROTECTED] (Matti Aarnio) writes: > > >NSes and MXes must ALWAYS point to NAMEs with A//A6 records for > >them, specifically those names MUST NOT be CNAMEs. With NSes the > > NS: must not > MX: should not > > ...stickler for details. ;-) > Henning > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] > > Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] > D-91054 Buckenhof Fax.: 09131 / 50654-20 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
mail loop
On Sun, 11 Feb 2001, Ben Ford wrote:
> Roger Larsson wrote:
>
> > OK, you had to...
> >
> > I have not seen any emails from linux-kernel for some days.
> > Even tried to resubscribe - Majordomo succeeded in sending me the Confirmation
> >
> > But nothing...
> >
>
> I must be getting all yours then!! Seriously, something's broke, I am getting
> duplicates of *every* *freaking* lkml message!!
>
> -b
That would be because we have a mail loop at techconsult.de ...
Received: from sys04.firma.ks ([213.252.152.243])
by mail2.cunet.de (8.11.2/8.11.2) with ESMTP id f1BHII811768;
Sun, 11 Feb 2001 18:18:19 +0100
Received: from router.techconsult.de (router [192.168.1.4]) by
sys04.firma.ks
with SMTP (Microsoft Exchange Internet Mail Service Version
5.5.2653.13)
id 1WFYLRCL; Sun, 11 Feb 2001 18:38:23 +0100
--
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]
Please read the FAQ at http://www.tux.org/lkml/
Re: Software Mestizo Manifesto
On Sun, 11 Feb 2001, Pavel Machek wrote: > Hi! > > > > > > Your "ethical" statement is incompatible with the GPL. > > > > > > I disagree. Its a statement. Its a request. It says 'advice'. Anyone is > > > entitled to advise how to use GPL software. The only issue is if someone > > > chooses to require it is not used by XYZ person. > > > > Please.. I am not lawyer... my intention were good, just to give authors > > the freedom to say "hey please dont drop a nuclear weapon in my city using > > my software" just that.. > > You may say "please don't drop nuclear weapon". You may *not* say "you > must not drop nuclear weapon", that would violate GPL. > Pavel "For all our friends who wish to rid the world of other races. This software is best operated with the computer plugged directly into the high voltage lines outside your house ..." 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [LK] Re: lkml subject line
On Mon, 12 Feb 2001, Mike Harrold wrote: > > Those would all be your problems and I would suggest using a different account > > for mail then. > > Out of interest, how would that solve anything? So I use an ISP instead. > Then I have to download all my mail to home to read it. Talk about a > total waste of time. > > It's hard enough tracking my mail as it is, let alone having to have another > account just to handle a certain mailing list. > Put procmail on the other account .. make it modify the subject as you wish then forward the mail to your regular account. 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://vger.kernel.org/lkml/
Re: lkml subject line
On Mon, 12 Feb 2001, Matthew D. Pitts wrote: > Pine, Mutt, there might be a few more. That's a load of crap ... why should pine filter when you have procmail just sitting there? > > Just my $0.02. > Matthew. > - Original Message - > From: Mohammad A. Haque <[EMAIL PROTECTED]> > To: Mike Harrold <[EMAIL PROTECTED]> > Cc: David Woodhouse <[EMAIL PROTECTED]>; Guest section DW > <[EMAIL PROTECTED]>; Matti Aarnio <[EMAIL PROTECTED]>; Guennadi > Liakhovetski <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Monday, February 12, 2001 1:45 PM > Subject: Re: lkml subject line > > > > Is there a mail reader nowadays that doesn't let you do some sort of > > filtering? > > > > On Mon, 12 Feb 2001, Mike Harrold wrote: > > > > > Assuming your mail reader can do that (and no, I can't change my mail > > > reader). > > > > > > /Mike > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://vger.kernel.org/lkml/ > > > > > > > -- > > > > = > > Mohammad A. Haque http://www.haque.net/ > >[EMAIL PROTECTED] > > > > "Alcohol and calculus don't mix. Project Lead > >Don't drink and derive." --Unknown http://wm.themes.org/ > >[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://vger.kernel.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://vger.kernel.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://vger.kernel.org/lkml/
Re: "Unable to load intepreter" on login - 2.2.14-5.0
On Mon, 12 Feb 2001, Tony Hoyle wrote: > Paul Tweedy wrote: > > > Secondly, to get the thing running I'm assuming I can copy a working login > > binary from an identical server, so I can get in & change the passwords and > > sort the security out? > > ...and what if the 'cp' binary has been hacked to stop you doing just > that? What if 'passwd' is silently emailing your root password to the > hacker each time you change it? > > Reformat and re-install. It's the only way (and check your firewall). Disabling all unneeded services would be a better idea than checking the firewall. I'm still not understanding this running by default most dists have going, it's stupid for servers and it's down right retarted for workstations. 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://vger.kernel.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: Plain 2.4.5 VM...
> * when you have an active process using ~300M of VM, in a ~380M machine, > 2/3 of the machine's RAM should -not- be soaked up by cache > > * when you have an active process using ~300M of VM, in a ~380M machine, > swap should not be full while there is 133M of RAM available. > > The above quoted is top output, taken during the several minutes where > cc1plus process was ~300M in size. Similar numbers existed before and > after my cut-n-paste, so this was not transient behavior. > > I can assure you, these are bugs not features :) > Ive seen that here too but every report I've sent on that has been dismissed as "that's what it's supposed to do" -- 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: [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/
[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: 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: 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: [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: [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: [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: 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: 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: 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/
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: 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/
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.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: 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: [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/
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) Cali
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- 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- S
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: [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: 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/
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: 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: 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: 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: [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/
[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: [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/
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.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/
[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: [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: 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: 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/
