Re: 2.4.x kernel BUG at filemap.c:81

[Todd Shetter <tshetter-lkml@earthlink.net>]

Jeff Garzik wrote:

> Marcelo Tosatti wrote:
>
>> On Wed, Feb 09, 2005 at 11:23:42PM -0500, Todd Shetter wrote:
>>
>>> Marcelo Tosatti wrote:
>>>
>>>
>>>> On Wed, Feb 09, 2005 at 03:47:28PM -0500, Todd Shetter wrote:
>>>>
>>>>
>>>>>>>>> Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 
>>>>>>>>> 2.4.28, 2.4.29 with highmem 4GB, and highmem i/o support 
>>>>>>>>> enabled, I get a system lockup. This happens in both X and 
>>>>>>>>> console. Happens with and without my Nvidia drivers loaded. I 
>>>>>>>>> cannot determine what makes this bug present it self besides 
>>>>>>>>> highmem and high i/o support enabled. Im guessing the system 
>>>>>>>>> is fine until highmem is actually used to some point and then 
>>>>>>>>> it borks, but I really have no idea and so im just making a 
>>>>>>>>> random guess. I ran memtest86 for a few hours a while ago 
>>>>>>>>> thinking that it may be bad memory, but that did not seem to 
>>>>>>>>> be the problem.
>>>>>>>>>
>>>>>>>>> If you need anymore information, or have questions, or wish me 
>>>>>>>>> to test anything, PLEASE feel free to contact me, I would 
>>>>>>>>> really like to see this bug resolved. =)
>>>>>>>>>
>>>>>>>>> Todd Shetter
>>>>>>>>>
>>>>>>>>> Feb  8 19:49:31 quark kernel: kernel BUG at filemap.c:81!
>>>>>>>>> Feb  8 19:49:31 quark kernel: invalid operand: 0000
>>>>>>>>> Feb  8 19:49:31 quark kernel: CPU:    0
>>>>>>>>> Feb  8 19:49:31 quark kernel: EIP:    0010:[<c01280d1>]    
>>>>>>>>> Tainted: P
>>>>>>>>>          
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Todd,
>>>>>>>> Why is your kernel tainted ?
>>>>>>>>
>>>>>>>
>>>>>>> I had the nvidia 1.0-6629 driver loaded when I got that error. I 
>>>>>>> compiled the kernel using the slackware 10.1 config, enabled 
>>>>>>> highmem 4GB support, highmem i/o, and then some kernel hacking 
>>>>>>> options including debugging for highmen related things.
>>>>>>>
>>>>>>> I booted, loaded X with KDE, opened firefox a few times, and 
>>>>>>> then started running hdparm because some newer 2.4.x kernels 
>>>>>>> dont play nice with my SATA, ICH5, and DMA. hdparm segfaulted 
>>>>>>> while running the drive read access portion of its tests, and 
>>>>>>> things locked up from there in about 30secs.
>>>>>>>
>>>>>>> I've gotten the same error with the nvidia driver not loaded, so 
>>>>>>> I dont think that is part of the problem.
>>>>>>>
>>>>>>> As I said, if you want me to test or try anything feel free to 
>>>>>>> ask.  =)
>>>>>>>
>>>>>>
>>>>>> Todd,
>>>>>>
>>>>>> Would be interesting to have the oops output without the kernel 
>>>>>> nvidia module. Do you have that saved?
>>>>>>
>>>>>
>>>>> Sorry, it took me FOREVER to get this bug to appear again, and 
>>>>> this time its a little different.
>>>>>  
>>>>>
>>>>
>>>> Hum, both BUGs are due to a page with alive ->buffers mapping.
>>>>
>>>> Did it crashed right after hdparm now too?
>>>> Can you boot your box without SATA drivers, configuring the 
>>>> interface to IDE mode ?
>>>>
>>>> Which problems are you facing with newer v2.4.x kernels and SATA?
>>>>
>>>
>>> Im waiting for the system to crash, so I figured I might as well get 
>>> on with the SATA problems....
>>>
>>> Running 2.4.29 neither the CONFIG_BLK_DEV_IDE_SATA nor the 
>>> CONFIG_SCSI_SATA are set currently and DMA is not enabled on either 
>>> of my drives,  hda: ST380013AS,  hdb: WDC WD2500SD-01KCB0,  hdc: 
>>> Maxtor 94610U6. Setting DMA manually on the hard drives yields a 
>>> HDIO_SET_DMA failed: Operation not permitted error.
>>>
>>> Using 2.4.26, DMA worked fine on the drives. Under 2.4.27, 2.4.28, 
>>> and 2.4.29 using CONFIG_SCSI_SATA does not allow setting of DMA on 
>>> the drives, yielding a HDIO_SET_DMA failed: Operation not permitted 
>>> error, and the transfer speeds reported by hdparm are at about 3MB/s.
>>
>>
>>
>> I think thats expected. Jeff?
>
>
> If (a) this is Intel ICH hardware and (b) it is running in combined 
> mode, it will get poor performance.
>
> For the SATA drivers, they ALWAYS run in DMA mode, so there is no need 
> to support HDIO_SET_DMA.
>
>     Jeff


Yes, I am running the SATA in combined mode. That, along with Auto mode, 
is the only way I can get all my devices to work properly under linux. 
Under Enhanced mode there is no primary IDE, only second and third. My 
ATA drive and CDROM are hdc and hdd, which is normal, my first SATA 
drive which would normally be hda should be hde and the other drive 
should be hdf. But the kernel doesnt see them and I cant boot off my 
normally hda, I get an invalid root= option kernel panic. I did edit 
lilo to reflect the change, but the drive wasnt even listed when hdc and 
hdd were. Under SATA only, I only get the SATA drives, and not my ATA 
drive nor my CDROM. With SATA diabled, I cant get the SATA drives at all 
which I expected.

Under Auto, which is the same as combined as far as I can tell, the 
kernel doesnt enable DMA for the drives using libata, and trying to 
enable it by hand yields the HDIO_SET_DMA failed: Operation not 
permitted error.

So, unless there is better performance from libata with ICH5 combined 
mode, I am 'forced' to stay with CONFIG_BLK_DEV_IDE_SATA, which isnt a 
bad thing really. I get good performance from the drives, and havent had 
any problems yet.

On a another note, kernel 2.4.30-pre1 with highmem is working fine for 
me, using CONFIG_BLK_DEV_IDE_SATA, uptime was a little over 2 days.

--
Todd Shetter