Re: htpt366 PCI latency value is really high
On Thu, 26 Apr 2007 18:30:33 +0400 Sergei Shtylyov <[EMAIL PROTECTED]> wrote: > Hello. > > Mike Mattie wrote: > > > while hunting down some latency problems I found something quite > > odd. The latency reported by lspci -v for the HTP203N card is > > enormous. > > > 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N > > (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 > > Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 17 > > I/O ports at ec00 [size=8] > > I/O ports at e800 [size=4] > > I/O ports at e400 [size=8] > > I/O ports at e000 [size=4] > > I/O ports at dc00 [size=256] > > Expansion ROM at dffe [disabled by cmd] [size=128K] > > Capabilities: [60] Power Management version 2 > > > I am assuming that the "latency" field here is the PCI latency timer > > which means this card is a bus hog. > > > From some reading on this issue linux methodically sets a sane > > value for all the PCI cards it sets up, which looks normal on the > > rest of the system, which is set to the value: 32 > >Hm, I'm only seeing clamping to the smallest of 64 and > pcibios_max_latency (255) in arch/i386/pci/i386.c if the latency > value is too low... Which arch are you using? > > > setting the value 32 with: > > > setpci -v -s "00:09.0" latency_timer=32 > > > 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N > > (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 > > Flags: bus master, 66MHz, medium devsel, latency 48, IRQ 17 > > I/O ports at ec00 [size=8] > > I/O ports at e800 [size=4] > > I/O ports at e400 [size=8] > > I/O ports at e000 [size=4] > > I/O ports at dc00 [size=256] > > Expansion ROM at dffe [disabled by cmd] [size=128K] > > Capabilities: [60] Power Management version 2 > > > Results in 48, which is not what I asked, but hopefully this is > > linux doing the right thing. output is decimal, input is hex - self-rtfm. >Not sure -- seems likely that it's the chip's own enforced minimum > instead... > > > I know this chipset is pretty brain-damaged, but is this > > high latency value a work-around for broken hardware, or > >More like it. Although HighPoint's own drivers force 64. > > > just a oversight ? > >Not likely since the value is too "special"... I have ran with a setting of 40 for a couple of days without any trouble. There are many reasons a card would default to a higher level, but in the end it is basically tuning the card for a server application. A warning that some cards default to high PCI latency values; settings that can interfere with latency sensitive devices such as sounds cards - this could be a help to others. 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 40, IRQ 19 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=256] Expansion ROM at dffe [disabled by cmd] [size=128K] Capabilities: [60] Power Management version 2 > > Cheers, > > Mike Mattie - [EMAIL PROTECTED] > > WBR, Sergei signature.asc Description: PGP signature
htpt366 PCI latency value is really high
Hello, while hunting down some latency problems I found something quite odd. The latency reported by lspci -v for the HTP203N card is enormous. 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 17 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=256] Expansion ROM at dffe [disabled by cmd] [size=128K] Capabilities: [60] Power Management version 2 I am assuming that the "latency" field here is the PCI latency timer which means this card is a bus hog. From some reading on this issue linux methodically sets a sane value for all the PCI cards it sets up, which looks normal on the rest of the system, which is set to the value: 32 setting the value 32 with: setpci -v -s "00:09.0" latency_timer=32 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 48, IRQ 17 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=256] Expansion ROM at dffe [disabled by cmd] [size=128K] Capabilities: [60] Power Management version 2 Results in 48, which is not what I asked, but hopefully this is linux doing the right thing. I know this chipset is pretty brain-damaged, but is this high latency value a work-around for broken hardware, or just a oversight ? Cheers, Mike Mattie - [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: recomended way to check longest period that interupts are disabled ?
On Thu, 26 Apr 2007 13:11:52 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > On Thu, 2007-04-26 at 04:02 -0700, Mike Mattie wrote: > > On Thu, 26 Apr 2007 11:53:57 +0200 > > Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 2007-04-26 at 02:13 -0700, Mike Mattie wrote: > > > > Hello, > > > > > > > > I am still struggling to track down problems with audio > > > > playback. I get intermittent: > > > > > > > > Apr 26 02:01:40 reforged [13230.947879] cannot submit sync urb > > > > (err = -45) > > > > > > > > I have tackled the scheduler issues to where I really don't > > > > think the driver is being starved at all. I am running > > > > audacious like so: > > > > > > > > schedtool -R -p 50 -n 1 -e audacious > > > > > > > > At this point the strongest correlation I can get is that > > > > starting programs seems to trigger the stutter. I have > > > > suspected IO for some time. > > > > > > > > My system image , / & /usr are on a libata (VIA PATA) driver. > > > > I have disabled the write-cache , but I also have noatime set > > > > on mount, for /usr > > > > > > > > My big suspicion is that one of my drivers, likely IO is > > > > disabling interrupts for too long. > > > > > > > > I have looked but not found a tool for measuring the longest > > > > period interrupts are disabled and pointing the finger at > > > > the culprit, could anyone on this list recommend tools that > > > > might help me pinpoint what is going on ? > > > > > > > > I would also be delighted for any sort of recommended latency > > > > testing tools. > > > > > > > > pin-pointing this is going to be a "learning experience" but > > > > every time I think I am about to have a bonding moment with > > > > the kernel audio skips; I am highly motivated. > > > > > > The -rt kernel contains a full latency tracer. > > > > > > http://people.redhat.com/mingo/realtime-preempt/ > > > > Thanks for the response. That is very helpful. I had > > looked at it briefly before but at a glance it looked > > like building a pro-audio workstation, which was a bit > > over the top for me. At a closer examination most of the > > stuff in -rt looks generally useful. > > > > > Some hardware just isn't up to the job though... > > > > I don't quite understand this. I have a athlon XP 3000+ > > and an audigy NX. Even using the libsamplerate library > > audacious + alsa only uses 12% of the processor tops. > > > > Some (broken) hardware, like some VIA IDE controllers just take > forever to do their thing. In which case you're stuck with it. Not > all x86 hardware is build to equal standards :-( > > quite honestly, x86 hardware is a mess. No disagreement there. It's really hard to pick good hardware other than remembering the odd kernel hacker comments , or grepping for expletives in the source and piping through wc :) > > > > my next step is to go out and buy a usb card so I can > > see if I can get the audigy NX on it's own interrupt. > > I'd try to pinpoint the latency first, might safe on expenses. definitely. > > from a look at -RT I need to do this before I can use > > the fun stuff like interrupt prioritization. > > > > Maybe a naive question but with the HIRES_TIMERS > > stuff merged, can the stats/diagnostics now merge > > into the mainline , or be broken out as a seperate patch ? > > Not sure, it might be. Ingo does all that. > > > I would really like to see what exactly the mainline is doing , > > especially so I can come up with a answer for what exactly is > > wrong with the current system. I would like to change > > my system knowing what the change is , rather than > > saying "-rt works but I don't know why". > > If its a hardware latency, -rt will suffer equally. Either way, > running -rt will teach you something. Either its mainline borkage, or > hardware. > > > One thought I had is that I could use the -rt patches > > as a starting place for some SystemTap probes. Looking > > down the road that seems to be the most durable option. > > Might be, although do remember that traps cost too. But I'm not really > familiar with all of this. > Thanks for the comments. After running cyclictest it definitely
recomended way to check longest period that interupts are disabled ?
Hello, I am still struggling to track down problems with audio playback. I get intermittent: Apr 26 02:01:40 reforged [13230.947879] cannot submit sync urb (err = -45) I have tackled the scheduler issues to where I really don't think the driver is being starved at all. I am running audacious like so: schedtool -R -p 50 -n 1 -e audacious At this point the strongest correlation I can get is that starting programs seems to trigger the stutter. I have suspected IO for some time. My system image , / & /usr are on a libata (VIA PATA) driver. I have disabled the write-cache , but I also have noatime set on mount, for /usr My big suspicion is that one of my drivers, likely IO is disabling interrupts for too long. I have looked but not found a tool for measuring the longest period interrupts are disabled and pointing the finger at the culprit, could anyone on this list recommend tools that might help me pinpoint what is going on ? I would also be delighted for any sort of recommended latency testing tools. pin-pointing this is going to be a "learning experience" but every time I think I am about to have a bonding moment with the kernel audio skips; I am highly motivated. Cheers, Mike Mattie - [EMAIL PROTECTED] signature.asc Description: PGP signature
rsdl v46 report,numbers,comments
he above concept is articulated from a distant background of programming a VGA adapter on a 286. That the last time I dealt with hard-deadlines hands on. I haven't had a reason to code at bare-metal since I started using linux so please consider it a vehicle for articulating a concept. 4. Outro In summary I like the RSDL scheduler quite a bit. It is consistent and doesn't do magic so I can build a priority scheme on-top of it with a very compact and reliable behavior model. Using the priority levels seems to allow me to use larger time-slices without sacrificing interactivity. This is unsuprising as I am actually telling the scheduler what I want .. I think that the window manager can use simple algorithms to calculate what the kernel would have to guess at with hairy heuristics. Hacking nice throttling into the window manager combined with a very simple but reliable scheduler may work pretty well for desktop users. Maybe that will excite someone enough to go try it, or dig up some existing implementation (other than OSX). I also think that SCHED_BATCH is where alot of fun experiments can be played. Especially in regards to CPU intensive programs. This combination is actually quite common I would think in audio/video production. At this point with how well my system works the itch has been scratched as far as the in-kernel part goes. I am interested though in playing around with your idlerun program though. Later on , possibly much later I will cook up some better numbers/comparisons. I really don't trust subjective evaluations of scheduling, my own included. I think people really want a new kernel patch to work better, which is a horrible way to start an evaluation. I want to measure both throughput, and interactivity in a double-blind like way. (random option for grub ?) With most of my work-load IO bound I expect the performance improvements to come from places like CFQ,ext4,syslet etc. Thank you to all for a good kernel. Linux user-space is quite comfortable these days. Cheers, Mike Mattie - [EMAIL PROTECTED] signature.asc Description: PGP signature
Re: [BUG] 2.6.21-rc7 hpt366 driver broken
On Mon, 16 Apr 2007 20:25:15 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
I have added Sergei Shtylyov to the address list after seeing his recent posts
on hpt366 issues, and the
git changelog for the hpt366.c driver. I am very confident that I have
pinpointed the defect in the driver.
> On Mon, 16 Apr 2007 19:43:03 -0700
> Mike Mattie <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 16 Apr 2007 18:21:12 -0700
> > Mike Mattie <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 16 Apr 2007 16:36:13 +0200
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > > [ Cc's added, full bug report was in
> > > > http://lkml.org/lkml/2007/4/16/18 ]
> > > >
> > > > On Mon, Apr 16, 2007 at 04:38:22AM -0700, Mike Mattie wrote:
> > > > > On Sun, 15 Apr 2007 22:48:46 -0700
> > > > > Mike Mattie <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am testing the 2.6.21-rc7 kernel release. The IDE hpt366
> > > > > > driver is crashing hanging the boot. I have basically the
> > > > > > same config as 2.6.20.7 which works fine (except for
> > > > > > netconsole mentioned in a previous mail).
> > > > > >
> > > > > > here is the hand-copied info:
> > > > > >
> > > > > > * "unable to handle paging request" , null deref
> > > > > > * EIP @ init_chipset_hpt366
> > > > > >
> > > > >
> > > > > > I am running a git-bisect to see if I can resolve it to a
> > > > > > commit.
> > > > >
> > > > > This was identified as the first broken commit:
> > > > >
> > > > > commit 7b73ee05d0acb926923d43d78b61add776ea4bb1
> > > > > Author: Sergei Shtylyov <[EMAIL PROTECTED]>
> > > > > Date: Wed Feb 7 18:18:16 2007 +0100
> > > > >
> > > > > hpt366: init code rewrite
> > > > >
> > > > > Reverting is conflicted so it will be a bit longer before I
> > > > > pin-point any other build-breaks.
> > > >
> > > > Thanks for your report.
> > > >
> > > > Can you use a digital camera for taking a photograph of the
> > > > crash?
> > >
> > > I can later on tonight, by about 11PM west coast. I also saw
> > > some hex offsets after the function pointed to by EIP, is there
> > > a way to decode that to a line number ? I have debugging symbols
> > > enabled.
> > >
> > > I am also doing printk breadcrumbs to pin it down to a block
> > > or a line.
> >
> > I have narrowed the crash with breadcrumbs down to these lines:
> >
> >
> > /*
> > * Only try the DPLL if we don't have a table for the PCI
> > clock that
> > * we are running at for HPT370/A, always use it for
> > anything newer... *
> > * NOTE: Using the internal DPLL results in slow reads on 33
> > MHz PCI.
> > * We also don't like using the DPLL because this causes
> > glitches
> > * on PRST-/SRST- when the state engine gets reset...
> > */
> > if (info->chip_type >= HPT374 || info->settings[clock] ==
> > NULL) { u16 f_low, delta = pci_clk < 50 ? 2 : 4;
> > int adjust;
> >
> > printk(KERN_INFO "inside the if\n");
> >
> > /*
> > * Select 66 MHz DPLL clock only if UltraATA/133
> > mode is
> > * supported/enabled, use 50 MHz DPLL clock
> > otherwise... */
> > if (info->max_mode == 0x04) {
> > dpll_clk = 66;
> > clock = ATA_CLOCK_66MHZ;
> > } else if (dpll_clk) { /* HPT36x chips don't
> > have DPLL */ dpll_clk = 50;
> > clock = ATA_CLOCK_50MHZ;
> > }
> >
> > if (info->settings[clock] == NULL) {
> crashes here
>
> since info is deref'd all over the place I am assuming it is the array
> that is blowing up.
>
> I printk'd the value of clock which is "4". that array is either not
> setup correctly , or it is out-of-bounds (speculation)
here on line 493: the hpt302n ( The chipset I have ) is the only struct without
a .settings field , I am extremely confident this is the exact location of the
Re: [BUG] 2.6.21-rc7 hpt366 driver broken
On Mon, 16 Apr 2007 19:43:03 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2007 18:21:12 -0700
> Mike Mattie <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 16 Apr 2007 16:36:13 +0200
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > [ Cc's added, full bug report was in
> > > http://lkml.org/lkml/2007/4/16/18 ]
> > >
> > > On Mon, Apr 16, 2007 at 04:38:22AM -0700, Mike Mattie wrote:
> > > > On Sun, 15 Apr 2007 22:48:46 -0700
> > > > Mike Mattie <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I am testing the 2.6.21-rc7 kernel release. The IDE hpt366
> > > > > driver is crashing hanging the boot. I have basically the same
> > > > > config as 2.6.20.7 which works fine (except for netconsole
> > > > > mentioned in a previous mail).
> > > > >
> > > > > here is the hand-copied info:
> > > > >
> > > > > * "unable to handle paging request" , null deref
> > > > > * EIP @ init_chipset_hpt366
> > > > >
> > > >
> > > > > I am running a git-bisect to see if I can resolve it to a
> > > > > commit.
> > > >
> > > > This was identified as the first broken commit:
> > > >
> > > > commit 7b73ee05d0acb926923d43d78b61add776ea4bb1
> > > > Author: Sergei Shtylyov <[EMAIL PROTECTED]>
> > > > Date: Wed Feb 7 18:18:16 2007 +0100
> > > >
> > > > hpt366: init code rewrite
> > > >
> > > > Reverting is conflicted so it will be a bit longer before I
> > > > pin-point any other build-breaks.
> > >
> > > Thanks for your report.
> > >
> > > Can you use a digital camera for taking a photograph of the crash?
> >
> > I can later on tonight, by about 11PM west coast. I also saw
> > some hex offsets after the function pointed to by EIP, is there
> > a way to decode that to a line number ? I have debugging symbols
> > enabled.
> >
> > I am also doing printk breadcrumbs to pin it down to a block
> > or a line.
>
> I have narrowed the crash with breadcrumbs down to these lines:
>
>
> /*
>* Only try the DPLL if we don't have a table for the PCI
> clock that
>* we are running at for HPT370/A, always use it for
> anything newer... *
>* NOTE: Using the internal DPLL results in slow reads on 33
> MHz PCI.
>* We also don't like using the DPLL because this causes
> glitches
>* on PRST-/SRST- when the state engine gets reset...
>*/
> if (info->chip_type >= HPT374 || info->settings[clock] ==
> NULL) { u16 f_low, delta = pci_clk < 50 ? 2 : 4;
> int adjust;
>
> printk(KERN_INFO "inside the if\n");
>
>/*
> * Select 66 MHz DPLL clock only if UltraATA/133
> mode is
> * supported/enabled, use 50 MHz DPLL clock
> otherwise... */
> if (info->max_mode == 0x04) {
> dpll_clk = 66;
> clock = ATA_CLOCK_66MHZ;
> } else if (dpll_clk) { /* HPT36x chips don't
> have DPLL */ dpll_clk = 50;
> clock = ATA_CLOCK_50MHZ;
> }
>
> if (info->settings[clock] == NULL) {
crashes here
since info is deref'd all over the place I am assuming it is the array
that is blowing up.
I printk'd the value of clock which is "4". that array is either not setup
correctly , or it is out-of-bounds (speculation)
> printk(KERN_ERR "%s: unknown bus timing!\n",
> name); kfree(info);
> return -EIO;
> }
>
> printk(KERN_INFO "select DPLL clock\n");
>
> This is right around 1171 , (skewed by the crumbs I added). The last
> message I receive is "inside if" , it dies before "select DPLL clock".
>
> Without knowing much about the structs I am not sure what to
> print-out. I will narrow it further, and maybe even compare against
> what the old working kernel had for variable values. That would take
> some time though.
>
> >
> > > cu
> > > Adrian
> > >
> > > --
> > >
> > >"Is there not promise of rain?" Ling Tan asked suddenly out
> > > of the darkness. There had been need of rain for many
> > > days. "Only a promise," Lao Er said.
> > >Pearl S. Buck - Dragon Seed
> > >
signature.asc
Description: PGP signature
Re: [BUG] 2.6.21-rc7 hpt366 driver broken
On Mon, 16 Apr 2007 18:21:12 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2007 16:36:13 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > [ Cc's added, full bug report was in
> > http://lkml.org/lkml/2007/4/16/18 ]
> >
> > On Mon, Apr 16, 2007 at 04:38:22AM -0700, Mike Mattie wrote:
> > > On Sun, 15 Apr 2007 22:48:46 -0700
> > > Mike Mattie <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hello,
> > > >
> > > > I am testing the 2.6.21-rc7 kernel release. The IDE hpt366
> > > > driver is crashing hanging the boot. I have basically the same
> > > > config as 2.6.20.7 which works fine (except for netconsole
> > > > mentioned in a previous mail).
> > > >
> > > > here is the hand-copied info:
> > > >
> > > > * "unable to handle paging request" , null deref
> > > > * EIP @ init_chipset_hpt366
> > > >
> > >
> > > > I am running a git-bisect to see if I can resolve it to a
> > > > commit.
> > >
> > > This was identified as the first broken commit:
> > >
> > > commit 7b73ee05d0acb926923d43d78b61add776ea4bb1
> > > Author: Sergei Shtylyov <[EMAIL PROTECTED]>
> > > Date: Wed Feb 7 18:18:16 2007 +0100
> > >
> > > hpt366: init code rewrite
> > >
> > > Reverting is conflicted so it will be a bit longer before I
> > > pin-point any other build-breaks.
> >
> > Thanks for your report.
> >
> > Can you use a digital camera for taking a photograph of the crash?
>
> I can later on tonight, by about 11PM west coast. I also saw
> some hex offsets after the function pointed to by EIP, is there
> a way to decode that to a line number ? I have debugging symbols
> enabled.
>
> I am also doing printk breadcrumbs to pin it down to a block
> or a line.
I have narrowed the crash with breadcrumbs down to these lines:
/*
* Only try the DPLL if we don't have a table for the PCI clock that
* we are running at for HPT370/A, always use it for anything newer...
*
* NOTE: Using the internal DPLL results in slow reads on 33 MHz PCI.
* We also don't like using the DPLL because this causes glitches
* on PRST-/SRST- when the state engine gets reset...
*/
if (info->chip_type >= HPT374 || info->settings[clock] == NULL) {
u16 f_low, delta = pci_clk < 50 ? 2 : 4;
int adjust;
printk(KERN_INFO "inside the if\n");
/*
* Select 66 MHz DPLL clock only if UltraATA/133 mode is
* supported/enabled, use 50 MHz DPLL clock otherwise...
*/
if (info->max_mode == 0x04) {
dpll_clk = 66;
clock = ATA_CLOCK_66MHZ;
} else if (dpll_clk) { /* HPT36x chips don't have DPLL */
dpll_clk = 50;
clock = ATA_CLOCK_50MHZ;
}
if (info->settings[clock] == NULL) {
printk(KERN_ERR "%s: unknown bus timing!\n", name);
kfree(info);
return -EIO;
}
printk(KERN_INFO "select DPLL clock\n");
This is right around 1171 , (skewed by the crumbs I added). The last
message I receive is "inside if" , it dies before "select DPLL clock".
Without knowing much about the structs I am not sure what to print-out.
I will narrow it further, and maybe even compare against what the old
working kernel had for variable values. That would take some time though.
>
> > cu
> > Adrian
> >
> > --
> >
> >"Is there not promise of rain?" Ling Tan asked suddenly out
> > of the darkness. There had been need of rain for many days.
> >"Only a promise," Lao Er said.
> >Pearl S. Buck - Dragon Seed
> >
signature.asc
Description: PGP signature
Re: [BUG] 2.6.21-rc7 hpt366 driver broken
On Sun, 15 Apr 2007 22:48:46 -0700 Mike Mattie <[EMAIL PROTECTED]> wrote: > Hello, > > I am testing the 2.6.21-rc7 kernel release. The IDE hpt366 driver is > crashing hanging the boot. I have basically the same config as > 2.6.20.7 which works fine (except for netconsole mentioned in a > previous mail). > > here is the hand-copied info: > > * "unable to handle paging request" , null deref > * EIP @ init_chipset_hpt366 > > I am running a git-bisect to see if I can resolve it to a commit. This was identified as the first broken commit: commit 7b73ee05d0acb926923d43d78b61add776ea4bb1 Author: Sergei Shtylyov <[EMAIL PROTECTED]> Date: Wed Feb 7 18:18:16 2007 +0100 hpt366: init code rewrite Reverting is conflicted so it will be a bit longer before I pin-point any other build-breaks. > Cheers, > Mike Mattie signature.asc Description: PGP signature
[BUG] 2.6.21-rc7 hpt366 driver broken
Hello, I am testing the 2.6.21-rc7 kernel release. The IDE hpt366 driver is crashing hanging the boot. I have basically the same config as 2.6.20.7 which works fine (except for netconsole mentioned in a previous mail). here is the hand-copied info: * "unable to handle paging request" , null deref * EIP @ init_chipset_hpt366 init_setup_hpt302 htp366_init_one ide_scan_pcidev ide_scan_pcibus ide_init init some hardware info: /usr/sbin/lspci -v | grep -i HPT -A 9 [EMAIL PROTECTED] 00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N (rev 02) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 18 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=256] Expansion ROM at dffe [disabled by cmd] [size=128K] Capabilities: I cannot get more information since netconsole is broken. I am running a git-bisect to see if I can resolve it to a commit. Cheers, Mike Mattie signature.asc Description: PGP signature
[BUG] netconsole hangs machine 2.6.20
Hello, netconsole is hanging my box during IDE init. I am running 2.6.20.7, config is attached from /proc Without using netconsole the kernel boots fine. I am writing this message from it. When I do enable net-console I get from the linux banner to a couple of lines after "sanitize end" on the logging client ( Mac OS X 10.4 , simple nc listener ) The boot continues until hde (handled by the HPT366 driver, hdg is the last drive ) and then the kernel just hangs. Also two previous mails to lkml have disappeared. Debugging is getting really hard when it is unbounded recursion :) Cheers, Mike Mattie config.gz Description: GNU Zip compressed data signature.asc Description: PGP signature
