AW: More E820 brokenness

<[EMAIL PROTECTED]> An: H. Peter Anvin <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED]; Joerg Pommnitz <[EMAIL PROTECTED]>; Chuck Ebbert <[EMAIL PROTECTED]>; Linux Kernel Mailing List ; Andi Kleen <[EMAIL PROTECTED]> Gesendet: Freitag, den 28. September 2007, 01:15:52 Uhr Bet

AW: More E820 brokenness

PROTECTED] An: H. Peter Anvin [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; Joerg Pommnitz [EMAIL PROTECTED]; Chuck Ebbert [EMAIL PROTECTED]; Linux Kernel Mailing List linux-kernel@vger.kernel.org; Andi Kleen [EMAIL PROTECTED] Gesendet: Freitag, den 28. September 2007, 01:15:52 Uhr Betreff: Re: More

Re: [GIT PULL] Workaround for broken Geode E820 BIOS

I just tried 2.6.23-rc8 with the patch applied. Works fine here, so my very first Acked-by: Joerg Pommnitz <[EMAIL PROTECTED]> for whatever it's worth, since it is already in Linus' tree. Thanks to Peter and Jordan for taking the interest and time to track this one down a

Re: [GIT PULL] Workaround for broken Geode E820 BIOS

I just tried 2.6.23-rc8 with the patch applied. Works fine here, so my very first Acked-by: Joerg Pommnitz [EMAIL PROTECTED] for whatever it's worth, since it is already in Linus' tree. Thanks to Peter and Jordan for taking the interest and time to track this one down and fix

RE: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800

> There is something very fishy. > > The only documentation you've given us so far is a screen shot which > contained a message ("BIOS data check successful") which doesn't occur > in the kernel. > > The loader string doesn't look all that familiar either; it looks like > an extremely old

Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800

PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 6560eb5b7e40d93813276544bced8c478f9067f5 fe5f90d9ca08e526559815789175602ba2c51743 M arch -- Regards Joerg - Ursprüngliche Mail Von: Jordan Crouse <[EMAIL PROTECTED]> An

Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800

] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 6560eb5b7e40d93813276544bced8c478f9067f5 fe5f90d9ca08e526559815789175602ba2c51743 M arch -- Regards Joerg - Ursprüngliche Mail Von: Jordan Crouse [EMAIL PROTECTED] An: Joerg Pommnitz [EMAIL PROTECTED] CC

RE: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800

There is something very fishy. The only documentation you've given us so far is a screen shot which contained a message (BIOS data check successful) which doesn't occur in the kernel. The loader string doesn't look all that familiar either; it looks like an extremely old version

RE: Problems with 2.6.23-rc6 on AMD Geode LX800

Chuck, Jordan, thanks for taking an interest in this problem. As suggested by Jordan I tried a new BIOS revision from http://www.digitallogic.ch/index.php?id=256=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21=23 Unfortunately the kernel still fails to boot in the same way. Do you still need

RE: Problems with 2.6.23-rc6 on AMD Geode LX800

Chuck, Jordan, thanks for taking an interest in this problem. As suggested by Jordan I tried a new BIOS revision from http://www.digitallogic.ch/index.php?id=256dir=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21mountpoint=23 Unfortunately the kernel still fails to boot in the same way. Do

Stable identification of identical USB hardware

Hello all, I want to be able to distinguish between two (or more) mostly identical USB serial devices. The devices in question are UMTS modems. AFAIK they are identical except for the SIM card and the point of attachment. Externally the cards are CardBus devices with an integrated USB host

Stable identification of identical USB hardware

Hello all, I want to be able to distinguish between two (or more) mostly identical USB serial devices. The devices in question are UMTS modems. AFAIK they are identical except for the SIM card and the point of attachment. Externally the cards are CardBus devices with an integrated USB host

Re: [Linux-usb-users] 2.6 PCMCIA/USB question

during development and I would like to avoid to many configuration files. Regards Joerg --- Alan Stern <[EMAIL PROTECTED]> wrote: > On Fri, 15 Apr 2005, Joerg Pommnitz wrote: > > > Hello all, > > I have a question that I could not figure out from other sources. I

2.6 PCMCIA/USB question

Hello all, I have a question that I could not figure out from other sources. I have the following hardware: an integrated CardBus USB host adapter with a connected USB serial device with three interfaces (normally ttyUSB0...ttyUSB2). Now I want to use 3 of these devices (remember: they are

2.6 PCMCIA/USB question

Hello all, I have a question that I could not figure out from other sources. I have the following hardware: an integrated CardBus USB host adapter with a connected USB serial device with three interfaces (normally ttyUSB0...ttyUSB2). Now I want to use 3 of these devices (remember: they are

Re: [Linux-usb-users] 2.6 PCMCIA/USB question

during development and I would like to avoid to many configuration files. Regards Joerg --- Alan Stern [EMAIL PROTECTED] wrote: On Fri, 15 Apr 2005, Joerg Pommnitz wrote: Hello all, I have a question that I could not figure out from other sources. I have the following hardware

Re: select(2), usbserial, tty's and disconnect

Robert Hancock wrote: > I thought this (hangup on remove [jpo]) had been merged, but I could be > wrong. I just checked bitkeeper. The patch went in some time ago: 4 months eolson 1.126 usb-serial: add tty_hangup on disconnect Regards Joerg

Re: select(2), usbserial, tty's and disconnect

Robert Hancock wrote: > There was discussion at one point about doing a tty_hangup() when the > USB device was disconnected (this causes the read() to return with 0 > > bytes and future open attempts to fail), and a patch was put out to do > this. I thought this had been merged, but I could be

Re: select(2), usbserial, tty's and disconnect

Robert Hancock wrote: There was discussion at one point about doing a tty_hangup() when the USB device was disconnected (this causes the read() to return with 0 bytes and future open attempts to fail), and a patch was put out to do this. I thought this had been merged, but I could be

Re: select(2), usbserial, tty's and disconnect

Robert Hancock wrote: I thought this (hangup on remove [jpo]) had been merged, but I could be wrong. I just checked bitkeeper. The patch went in some time ago: 4 months eolson 1.126 usb-serial: add tty_hangup on disconnect Regards Joerg

select(2), usbserial, tty's and disconnect

Hello all, currently it seems that select keeps blocking when the USB device behind ttyUSBx gets unplugged. My understanding is, that select should return when the next call to one of the operations (read/write) will not block. This is certainly true for failing with ENODEV. So, is this an issue

select(2), usbserial, tty's and disconnect

Hello all, currently it seems that select keeps blocking when the USB device behind ttyUSBx gets unplugged. My understanding is, that select should return when the next call to one of the operations (read/write) will not block. This is certainly true for failing with ENODEV. So, is this an issue

Re: Alan Cox quote? (was: Re: accounting for threads)

> But that foregoes the point that the code is far more complex and > harder to make 'obviously correct', a concept that *does* translate > well to userspace. Check the state threads library from SGI: http://oss.sgi.com/projects/state-threads/ It should provide the code clarity one is used

Re: Alan Cox quote? (was: Re: accounting for threads)

But that foregoes the point that the code is far more complex and harder to make 'obviously correct', a concept that *does* translate well to userspace. Check the state threads library from SGI: http://oss.sgi.com/projects/state-threads/ It should provide the code clarity one is used from

Re: TCP capture effect :: estimate queue length ?

> Pathchar, yet another Van Jacobsen toy does this. Unfortunately the old > and rotten pre-version you can find in ftp.ee.lbl.gov/pathchar/ is afaik > the last one. In the past it served me well you find about how ISPs are > lying ... 100mbit backbone = fast ethernet in their computer room ...

Re: TCP capture effect :: estimate queue length ?

Pathchar, yet another Van Jacobsen toy does this. Unfortunately the old and rotten pre-version you can find in ftp.ee.lbl.gov/pathchar/ is afaik the last one. In the past it served me well you find about how ISPs are lying ... 100mbit backbone = fast ethernet in their computer room ... clink

Re: "mount -o loop" lockup issue

Ah, now you are arguing semantics. When somebody writes something to improve the Linux kernel this makes them part of the Linux kernel community. The project might be a new file system or a tool to verify the consistency of certain rules. The CHECKER people set out to make a tool that finds

Re: "mount -o loop" lockup issue

David Konerding <[EMAIL PROTECTED]> wrote: > But the attitude that "many eyes make all bugs shallow" and "let the > users test the code for us" just don't hold up. For the former, > clearly, many eyes didn't find a lot of basically obvious bugs, for the > latter, it's just impolite. You

Re: mount -o loop lockup issue

David Konerding [EMAIL PROTECTED] wrote: But the attitude that "many eyes make all bugs shallow" and "let the users test the code for us" just don't hold up. For the former, clearly, many eyes didn't find a lot of basically obvious bugs, for the latter, it's just impolite. You

Re: Better than SYNcookies?

Here is a message from nntp://news.grc.com/news.feedback Somebody with good knowledge of the Linux SYN-Cookies should probably drop by and discuss the matter... Regards Joerg Subject: A *significant* dilemma . . . Date: Mon, 25 Sep 2000 13:15:59 -0700 From: Steve Gibson <[EMAIL

Re: Better than SYNcookies?

Here is a message from nntp://news.grc.com/news.feedback Somebody with good knowledge of the Linux SYN-Cookies should probably drop by and discuss the matter... Regards Joerg Subject: A *significant* dilemma . . . Date: Mon, 25 Sep 2000 13:15:59 -0700 From: Steve Gibson [EMAIL PROTECTED]