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
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
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
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
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]>
>
> ---
xattr+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 that, everything seems fine and dandy on this plain old P3.
HTH, and Happy
at an earlier point in the
system's life.
Other than that, everything seems fine and dandy on this plain old P3.
HTH, and Happy New Year everyone
Tilman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
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]
---
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)
> 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
> 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
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
> 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
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
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
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
> > 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
> > 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
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
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
> 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
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
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
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 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
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
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 that
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
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
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.
*It
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.
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.
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 going
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 let alone
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
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
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
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
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
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. BTW
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 cleaare
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)
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
alds/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" in
the body of a message to [E
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
> * 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.
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
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
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
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
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
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 server so that is why I was noticed with &qu
.: 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 server so that is why I was noticed with fatal: unexpected EOF git
message.
--
- Cyrill
-
To unsubscribe from
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 for
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
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
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
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
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.6.20-rc
* 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.
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 the
-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 in
the body of a message to [EMAIL PROTECTED]
More
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 the fix
d.
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
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.
> 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
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 is
-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.
Linus
Adrian Bunk (2):
V4L/DVB (4959): Usbvision: possible cleanups
V4L/DVB (4991): Cafe_ccic.c: fix NULL
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
?
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/
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
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
the one
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
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
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
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 who was
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?*).
All
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 it
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
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
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
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
>
> 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
hang 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
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
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
1 - 100 of 136 matches
Mail list logo
