John Baldwin wrote:
On an i386 8.0 kernel built here it is this line:
139 if ((error = ch->dma.load(request, NULL, &dummy))) {
which would seem to indicate dma.load is NULL somehow. My patch doesn't
affect that part of the code at all. Are you using any modules or is ata
compile
On Wednesday 10 June 2009 4:39:53 am Bruce Simpson wrote:
> John Baldwin wrote:
> > http://www.FreeBSD.org/~jhb/patches/ata_ali.patch
> > Ok, I've uploaded the patch, I must have just sent it inline before.
> >
>
> Thanks!
>
> I did a p4 integ on my p4 work branch, built a NanoBSD USB stick im
John Baldwin wrote:
As far as I know the regression / panic still happens in 7.2 -- I nearly
did an 'installkernel' on that box w/o thinking...
Yes. The same patch will apply to 7-stable though it will have to be applied
to ata-chipset.c instead.
Here is that patch reworked, which I'm
John Baldwin wrote:
http://www.FreeBSD.org/~jhb/patches/ata_ali.patch
Ok, I've uploaded the patch, I must have just sent it inline before.
Thanks!
I did a p4 integ on my p4 work branch, built a NanoBSD USB stick image
with this patch incorporated into the kernel, booted from it
successful
On Tuesday 09 June 2009 6:40:38 am Bruce Simpson wrote:
> John,
>
> John Baldwin wrote:
> > Were you ever able to test
http://www.FreeBSD.org/~jhb/patches/ata_ali.patch?
> >
> >
>
> Fraid not, thanks for the reminder... I have been sidetracked...
>
> Unfortunately that patch doesn't seem to
John,
John Baldwin wrote:
Were you ever able to test http://www.FreeBSD.org/~jhb/patches/ata_ali.patch?
Fraid not, thanks for the reminder... I have been sidetracked...
Unfortunately that patch doesn't seem to be there now, and I didn't have
a copy downloaded.
I can try to make time now
On Sunday 17 May 2009 7:52:04 pm Bruce Simpson wrote:
> Alexander Motin wrote:
> > ...
> > This change is not anyhow related to your system. Looks like the real
> > reason found by jhb@ on sta...@. Probably something become more strict
> > in system resource management last time and this driver v
Alexander Motin wrote:
...
This change is not anyhow related to your system. Looks like the real
reason found by jhb@ on sta...@. Probably something become more strict
in system resource management last time and this driver violates now.
Thanks... I reckon John is probably on the money with
Bruce Simpson wrote:
Alexander Motin wrote:
Bruce Simpson wrote:
Could this commit have broken boot on my amd64 system with an ULi
SATA controller?
This commit could change driver used for controller and so expose some
other bug in ALI driver. As I can see, there is present
vendor-specific
Alexander Motin wrote:
Bruce Simpson wrote:
Could this commit have broken boot on my amd64 system with an ULi
SATA controller?
This commit could change driver used for controller and so expose some
other bug in ALI driver. As I can see, there is present
vendor-specific driver for this chip,
Bruce Simpson wrote:
Could this commit have broken boot on my amd64 system with an ULi SATA
controller?
This commit could change driver used for controller and so expose some
other bug in ALI driver. As I can see, there is present vendor-specific
driver for this chip, but without pciconf outp
Hi,
Could this commit have broken boot on my amd64 system with an ULi SATA
controller?
I have not fully bisected (and to be honest, who really has time to do
this for production machines, unless
The panic I get with RELENG_7 sources as of yesterday after this commit
is 'resource list busy'
12 matches
Mail list logo
