File Attachment Problem - again!

[Paul]

Originally posted by Prince
It was actually a "Cannot find server page".

Ahh, okay--that makes sense

[Prince]

It was actually a "Cannot find server page".

but the problem turned out to be server related. When I upgraded to my current dedicated server DMA was not enabled on the hard drive, thus causing huge CPU load spikes.
Once my web host enabled it my drive through put went from 4meg/second to 34meg/second.

[Paul]

Originally posted by Prince
When an attachment is added to a post it hangs for a minute then goes to a 404 error page.

The 404 error page is pretty weird. When you have errors in other php scripts, is the error displayed (i.e. You have an error in /home/site/public-html/something.php on line 321) or are you redirected to a 404? Perhaps your host has some funky setup for error reporting? Do you experience this using browsers other than IE?

I know IE likes to make up it's own error pages in certain situations where the error page sent from the server is smaller than a certain file size. Try with Netscape or some other browser and see what happens.

*shrug*

Good luck,
Paul

[Floris]

In order to see if it is maybe vBulletin -
In your Admin control panel > vbulletin options > attachments : how much mb do you allow to get uploaded per attachment?
And if you try to upload a little .txt file with just one line of text, does it also give that error?
How much does your PHP allow to upload before it times out? (you can check with <?php phpinfo(); ?> in a test.php file.
The weird thing is, it doesn't give an vbulletin 'file is too large' error, and displays a 404 .. This doesn't have to mean it can't find an url, but could also mean it has timed out the request to process it. In that case, your hosting provider might be right.

[Prince]

When an attachment is added to a post it hangs for a minute then goes to a 404 error page.

I can upload smilies just fine though.

I spoke with my web host and they said this:

I see that the hard drive is not in
DMA mode..

[email protected] [~]# /sbin/hdparm -v /dev/hda

/dev/hda:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 7474/255/63, sectors = 120069936, start
= 0

busstate = 1 (on)

I am going to pass this to someone who knows the hardware better than I do to determine if it will be safe to enable DMA on the drive, I believe that is the problem (kswapd is what takes up the CPU).

would this cause a problem?