Dear Friend,
I came across your e-mail contact prior a private search while in need
of your assistance. My name is Aisha Gaddafi a single Mother and a
Widow with three Children. I am the only biological Daughter of late
Libyan President (Late Colonel Muammar Gaddafi).
I have an investment funds
--
I solicit your cooperation in a $7 Million transaction business that
will benefit both of us and i need your trust reply for more details.
Kind regards
Victoria.
Thanks for your response :).
Please Spread the word regarding the copyright-holders rights (remeber:
the
Linux kernel programmers did not sign over their copyrights, one of the
reasons Linux grew so quickly amongst developers where GNU very slowly
(The FSF will only include code where the copyr
I have a very profitable business proposal for you
I am Mr.Sheng Li Hung, from china I got your information while search for
a reliable person, I have a very profitable business proposition for you
and i can assure you that you will not regret been part of this mutual
beneficial transaction after completion. Kindly get back to me for more
details o
From: Carl Leinbach
Sent: Wednesday, January 06, 2016 4:13 PM
To: Carl Leinbach
Subject: Happy New Year
You Have Been
Picked...Email:(mr_sgloria_macken...@email.com<mailto:mr_sgloria_macken...@email.com>)
For More Details
--
To unsubscribe from thi
On Tue, 2007-01-02 at 11:58 +, Alan wrote:
...
>
> I'm sending this now rather than after running full test suites so that
> it can get the maximal testing in a short time. I'll be running tests on
> this after lunch.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> --- linux.vanilla-2
s_setxattr+0xa6/0x1ff
[] setxattr+0xb9/0xd1
[] sys_lsetxattr+0x3e/0x50
[] sysenter_past_esp+0x5f/0x99
===
I guess it's really the same ReiserFS issue I already reported for
the previous releases, just triggered at an earlier point in the
system's life.
Other than th
Alan wrote:
Once combined mode is fixed not to abuse resources (and it originally
did it that way for a good reason I grant and am not criticising that) the
entire management for legacy mode, mixed mode and native mode resources
for an ATA device (including 0x170, 0x3F6 and other wacky magic) bec
> Thus, if you avoid calling pci_request_regions (as your patch does), you
> must manually provide the same guarantees that pci_request_regions
> provides to its callers.
pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the
fact the resources are mashed and eventually cleaar
> 1) Programmatically reserve /all/ resources associated with
> our PCI device
> 2) Manually reserve resources associated with our PCI device,
> but are not listed in struct pci_dev.
Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the
other register.
Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is
written to assume that /all/ struct pci_dev resources for a single PCI
device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you
mus
Alan wrote:
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
(a) I'm well of aware of this, and (b) that changes nothing.
I said
> 2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
> libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
never r
Alan wrote:
Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because
of the PCI resource mismanagement in the old tree. So you take your pick.
I pick old bugs over new regressions.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Alan wrote:
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
False:
2.6.0 - 2.6.19: libata guarantees that all
On Tue, 02 Jan 2007 16:32:01 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jeff Garzik wrote:
> > * After your patch, the code explicitly calls pci_request_region() for
> > BARs 0-4, but never for BAR5.
>
> Without checking for failures, I might add.
The old code didn't reserve 1 or 3 at all l
> > We use BAR5 on two devices in legacy mode. Both of those reserve all the
> > other resources.
>
> Translation: You want to hand-wave away an obvious regression that YOU
> have created with your fix-to-a-fix.
It's not regressing anything.
> Why INTRODUCE these 2.6.20 Alan-isms, if they are
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code
actually CARED if the resource was reserved.
Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it work
> > This is a silly complaint because the SFF layer in libata doesn't handle
> > this case yet anyway.
>
> Yes, it's "silly" people people use configurations you find inconvenient.
>
> At least one embedded x86 case cares, that I know of. They only needed
> to make two minor changes to make it
Alan wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one cha
On Tue, Jan 02, 2007 at 11:58:34AM +, Alan wrote:
> This is a slight variant on the patch I posted December 16th to fix
> libata combined mode handling. The only real change is that we now
> correctly also reserve BAR1,2,4. That is basically a neatness issue.
Thanks,
I can confirm that with t
On Mon, 1 Jan 2007, Alan wrote:
>
> If you revert the commit you end with all the PCI resource tree breakage
> back
Which weren't a regression or anything new.
Alan: regressions are what we don't do. Ever. If your second patch is
found to have some other problems, we revert them both. It's th
> Appears to work just fine here (compiles, boots and I'm
> typing this email :). The build warnings below seem new
> to me - but I guess they're harmless...
They are harmless. For the 2.6.21 code base they will go away as well.
-
To unsubscribe from this list: send the line "unsubscribe linux-
On 1/2/07, Alan <[EMAIL PROTECTED]> wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it did
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native on
On Mon, Jan 01, 2007 at 03:34:53PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 1 Jan 2007, Alan wrote:
> >
> > Want a fix Linus given Jeff is away ?
>
> Send it over, and please cc Alessandro and others that can test it. Things
> obviously aren't broken on _my_ machines ;)
Can I get a copy of t
inux/kernel/git/torvalds/linux-2.6.git' failed.
What's wrong?
Happy New Year ;)
Look at http://www.kernel.org/. Currently, the git daemon stops serving
new clients at loadavg 200.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Mon, 1 Jan 2007, Alan wrote:
>
> Want a fix Linus given Jeff is away ?
Send it over, and please cc Alessandro and others that can test it. Things
obviously aren't broken on _my_ machines ;)
And if we end up having more problems related to this in -rc4, I'll just
revert both your fix and th
> * I was unable to argue against Alan's logic behind
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it.
> Regardless of whether or not this truly reflects how the PCI device is
> wired, it makes pci_request_regions() and similar resource handling code
> behave differently.
C
On Mon, 1 Jan 2007 12:13:08 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Jeff,
> what was the resolution to this one? Just revert the offending commit, or
> what?
If you revert the commit you end with all the PCI resource tree breakage
back
>
> We're about five weeks into the 2.
Linus Torvalds wrote:
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be activ
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be actively fixed. By forcible
The final 2.6.20 release note should mention the following commit in some
way: "[NETFILTER]: Kconfig: improve conntrack selection"
It will break existing iptable setups without warning becausee it
disables all related .config options. If one says NO to the new
NF_CONNTRACK_ENABLED "Netfilter conne
On 1/1/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
In order to not get in trouble with MADR ("Mothers Against Drunk
Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for ev
On Monday 01 January 2007 02:19, Linus Torvalds wrote:
> In order to not get in trouble with MADR ("Mothers Against Drunk
> Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
> for midnight, because it's bound to be new years _somewhere_ out there. So
> here's to a happy 2007
r
| that I was able to get 2.6.20-rc3 out - compiling now. So perhaps just
| try it again...
| Petr
|
| P.S.: Happy New Year. Here in California we still have 15 minutes of
| year 2006 to go.
|
|
|
Yea, I've got linux git clone later. I think that was some files activity
on git serv
linux-2.6.git' failed.
What's wrong?
Happy New Year ;)
--
- Cyrill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sun, Dec 31, 2006 at 05:19:44PM -0800, Linus Torvalds wrote:
> Alexey Dobriyan (2):
> V4L/DVB (5012): Usbvision fix: It was using "&&" instead "&"
> fuse: fix typo
Second is from Thomas Hisch <[EMAIL PROTECTED]>, actually.
-
To unsubscribe from this list: send the line "unsubscribe
ate by the
>time the hangovers are mostly gone.
>
>At which point the first thing on any self-respecting geek's mind should
>obviously be: "is there a new kernel release for me to try?"
>
>Right?
>
Right. Have a Happy New Year yourself, Linus.
>
In order to not get in trouble with MADR ("Mothers Against Drunk
Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for everybody.
The big thing at least for me personally i
Russell King <[EMAIL PROTECTED]> writes:
> Kai Germaschewski writes:
> > The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when
> > I found what was really going on. Other source files used a global
> > initialized variable "divert_if" as well, so this became the same one as
>
Kai Germaschewski writes:
> The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when
> I found what was really going on. Other source files used a global
> initialized variable "divert_if" as well, so this became the same one as
> the one referenced in isdn_common.c. That's why
On 3 Jan 2001, Eric W. Biederman wrote:
> Kai Germaschewski <[EMAIL PROTECTED]> writes:
>
> > I think the problem was that we relied on divert_if being initialized to
> > zero automatically, which didn't happen because it was not declared static
> > and therefore not in .bss (*is this true?*).
>
Kai Germaschewski <[EMAIL PROTECTED]> writes:
> On Tue, 2 Jan 2001, Gerold Jury wrote:
>
> > I have reversed the patches part by part, the only thing that makes a
> > difference is the diversion services.
> > The reason for this remains unknown for me.
>
> I think I found it. Could everybody wh
On Tue, 2 Jan 2001, Kai Germaschewski wrote:
> I think the problem was that we relied on divert_if being initialized to
> zero automatically, which didn't happen because it was not declared static
> and therefore not in .bss (*is this true?*).
This is true in this particular case, and your added
On Tue, 2 Jan 2001, Gerold Jury wrote (in a private message, sorry):
> The machine is single CPU no SMP.
> It hangs with or without X when i hangup the ippp0 interface.
> One of the scripts that run when the line is hung up may do a ifconfig
> ippp0 down afterwards which could be the actual reas
It works for me.
With and without the divert module loaded.
Thanks a lot
Gerold
Kai Germaschewski wrote:
> I think I found it. Could everybody who was getting the crash on ISDN line
> hangup try if the following patch fixes the problem?
>
-
To unsubscribe from this list: send the line "unsub
Linus Torvalds <[EMAIL PROTECTED]> writes:
> > [...] the drm modules have unresolved symbols:
>
> Does this fix it for you (do a "make clean" before re-building your tree)?
Yep, that works for a modular mga.o (although it also results in
drmlib.a being installed into /lib/modules, which makes d
On Tue, 2 Jan 2001, Gerold Jury wrote:
> I have reversed the patches part by part, the only thing that makes a
> difference is the diversion services.
> The reason for this remains unknown for me.
I think I found it. Could everybody who was getting the crash on ISDN line
hangup try if the follow
>
> On Sun, 31 Dec 2000, Linus Torvalds wrote:
>
> > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> > last-minute stuff that needed fixing (ie the dirty page lists etc), and
> > the best I can do is make a prerelease.
>
> I just compiled that one into a 1032 kB kernel, and i
g when i hangup the isdn line.
> I have reversed the patch for all occurences of INIT_LIST_HEAD in the
> isdn patch part and it works for me now.
>
> The relevant part is attached. Please back it out for 2.4.0.
>
> Happy new year
>
> Gerold Jury
>
-
To unsubscribe fr
> haven't finished this work yet. With this new work, however, the
> end-user will still load a single module (e.g., tdfx.o), just like now.
> (Loading a single kernel module is a significant win when dealing with
> end users: there is no possibility of version skew or of having two
> modules tha
On Tue 2 Jan 2001 08:32:45 +1100,
Keith Owens <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Jan 2001 09:39:38 -0800 (PST),
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >On 1 Jan 2001, Adam Sampson wrote:
> >>
> >> It appears to work (even with the reiserfs patch with the obvious
> >> Makefile twea
On Tue, 2 Jan 2001, Thorsten Kranzkowski wrote:
> On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
> > The ISDN changes for the HISAX drivers
> > that came in since test12 have introduced a bug that causes a
> > AIEE-something and a complete kernel hang when i hangup the isdn line.
>
After a long session of heavy use I triggered the BUG at inode.c line
372 in clear_inode:
if (inode->i_data.nrpages)
BUG();
This occured when a gdb xte
On Tue, 2 Jan 2001, Matthias Andree wrote:
> On Sun, 31 Dec 2000, Linus Torvalds wrote:
>
> > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> > last-minute stuff that needed fixing (ie the dirty page lists etc), and
> > the best I can do is make a prerelease.
>
> I just compi
On Sun, 31 Dec 2000, Linus Torvalds wrote:
> Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> last-minute stuff that needed fixing (ie the dirty page lists etc), and
> the best I can do is make a prerelease.
I just compiled that one into a 1032 kB kernel, and it failed to be
bo
[EMAIL PROTECTED] said:
> I'm using the hisax driver too (build in), and it works perfectly for
> me.
I've also seen my machine die on taking down the ippp0 interface
("service isdn stop") - not on hanging up ("isdnctrl hangup ippp0").
I keep forgetting to investigate, because it's extremely
On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
> The ISDN changes for the HISAX drivers
> that came in since test12 have introduced a bug that causes a
> AIEE-something and a complete kernel hang when i hangup the isdn line.
> I have reversed the patch for all occurences of INIT_LIS
relevant part is attached. Please back it out for 2.4.0.
Happy new year
Gerold Jury
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/config.c
linux/drivers/isdn/hisax/config.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/config.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn
On Mon, 1 Jan 2001 09:39:38 -0800 (PST),
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On 1 Jan 2001, Adam Sampson wrote:
>>
>> It appears to work (even with the reiserfs patch with the obvious
>> Makefile tweak), but the drm modules have unresolved symbols:
>
>Does this fix it for you (do a "make
Linus Torvalds wrote:
> On 1 Jan 2001, Adam Sampson wrote:
> >
> > It appears to work (even with the reiserfs patch with the obvious
> > Makefile tweak), but the drm modules have unresolved symbols:
>
> Does this fix it for you (do a "make clean" before re-building your tree)?
>
>
Linus Torvalds wrote:
> Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> last-minute stuff that needed fixing (ie the dirty page lists etc), and
> the best I can do is make a prerelease.
It's even better this way. Now we kick off the new millenium with a new
kernel. :-)
--
Da
On 1 Jan 2001, Adam Sampson wrote:
>
> It appears to work (even with the reiserfs patch with the obvious
> Makefile tweak), but the drm modules have unresolved symbols:
Does this fix it for you (do a "make clean" before re-building your tree)?
Linus
--- v2.4.0-prerelease
Eric W. Biederman writes,
>Some arches have separate maintenance but I don't believe alpha is.
>Though I do believe it has a separate mailing list for alpha specific
things,
>to get better signal to noise ratio.
Great! Do you know where I can find more info about it?
--Ray
-
To unsubscribe from
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> last-minute stuff that needed fixing (ie the dirty page lists etc), and
> the best I can do is make a prerelease.
It appears to work (even with the reiserfs patch with the obvious
Make
>I want people to test it for a while, and I want to give other
architectures >the chance to catch up with some of the changes
Does that mean that other architectures have separate mailing lists and
kernel source trees? Is that why i've been getting ignored =)?
If so, what are they? I'd really li
Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
last-minute stuff that needed fixing (ie the dirty page lists etc), and
the best I can do is make a prerelease.
There's a 2.4.0-prerelease out there, and this is basically it. I want
people to test it for a while, and I want to giv
70 matches
Mail list logo
